[OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType

Wed Oct 29 19:08:17 CET 2014

Dear Vladimir,

I believe that mandating what each individual implementation may or may not
support is out of scope of the OFF standard

Well, "mandating" is certainly out of scope, but identifying which
combination of tools are used and recording them as "profiles"is what MPEG
has been doing since late 1992.

Judging from the number of (used) profiles in MPEG and the number of
different organisations that employ the profile approach, it looks like
"profile" is a standard and market friendly approach to problem solving

Leonardo 

Visit  <http://leonardo.chiariglione.org/> Leonardo's web site

 <http://leonardo.chiariglione.org/> 

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On
Behalf Of 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com
[mpeg-OTspec]
Sent: Wednesday, 29 October, 2014 17:55
To: Sairus Patel; mpeg-OTspec at yahoogroups.com; Cameron McCormack; Chris
Lilley
Subject: RE: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType

Hi Sairus,

I am at the W3C TPAC meeting this week (in Santa Clara), and Chris, Behdad
and I had a chance to discuss whether the compressed SVG encoding is already
part of the specification that we are referencing. If this is the case, it
is indeed possible to simply add a clarification language to the text of the
standard to explain what types of SVG encodings that can be used for glyph
descriptions, and this is definitely something that can also be
independently described in the appropriate section of the SVG Integration
document. Behdad has agreed to review the current OFF text and make a
proposal on what parts need to be changed / clarified, and I will talk to
Chris to discuss the details.

When it comes to implementations - I believe that mandating what each
individual implementation may or may not support is out of scope of the OFF
standard. We define technologies and tools to enable certain levels of
functionality, and in order to ensure interoperability the OFF spec does
define a core set of required tables but it would be too overreaching to try
to mandate what a particular implementations do as their supported
functionality is usually determined by target markets / language
/application requirements. I don't think we can change that easily.

Thank you,
Vlad

-----Original Message-----
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On
Behalf Of Sairus Patel sppatel at adobe.com [mpeg-OTspec]
Sent: Wednesday, October 29, 2014 10:36 AM
To: opentype-list at indx.co.uk; mpeg-OTspec at yahoogroups.com; Cameron
McCormack; Chris Lilley
Subject: Re: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType

Cam/Chris, could support of such encodings (gzip, deflate) be seen as
required of SVG viewers even for an "SVG Integration" such as SVG-in-OT?
Or could the encodings be restricted just to plaintext and gzipped content
for SVG-in-OT? Is there a reason to reject deflate? Perhaps all should be
allowed, and the fact that certain impls may not support all of them could
be pointed out in the spec and seen as an impl limitation. The font-making
world already has many "best/prudent practices" to keep in mind and this
will be one of them.

Vlad: if it's clear that this is a clarification, can it be added without
going through the amendment process? That would simplify things, e.g. for
developers who right now don't have a central place to find the latest
SVG-in-OT spec.

By the way, all the color formats are OpenType (well, OFF) now, and are not
Adobe/Mozilla's or Microsoft's or Google's. In my view, impls should try to
or aim to support all of them: SVG, glyph overlay, and color bitmaps, just
as impls should aim to support CFF as well as TT.

Sairus

-----Original Message-----
From: Behdad Esfahbod <behdad at behdad.org>
Reply-To: "opentype-list at indx.co.uk" <opentype-list at indx.co.uk>
Date: Sunday, October 26, 2014 at 6:04 PM
To: "listmaster at indx.co.uk" <listmaster at indx.co.uk>
Subject: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType

>Message from OpenType list:
>
>
>Thanks Chris,
>
>On 14-10-26 05:07 PM, Chris Lilley chris at w3.org [mpeg-OTspec] wrote:
>> 
>> 
>> Hello Behdad,
>> 
>> Saturday, October 25, 2014, 9:56:18 AM, you wrote:
>> 
>>> Allow gzip-compressed SVG documents where SVG documents are 
>>> currently accepted.
>> 
>> This is a useful clarification. I say clarification because a 
>> conforming SVG viewer is already required to accept gzip-compressed
>> content:
>> 
>> SVG implementations must correctly support gzip-encoded [RFC1952] and 
>> deflate-encoded [RFC1951] data streams, for any content type 
>> (including SVG, script files, images).
>
>Right. You mentioned this before, and I tried to confirm it, but got 
>confused and thought the requirements only affect HTTP transport. I 
>checked again now and see your point.
>
>This distinction is important though, because if your reasoning is to 
>be followed, then deflate-encoded SVG must also be supported.
>
>However, from the point of view of SVG+OpenType specification / working 
>group, they may not feel bound by the SVG viewer conformance 
>requirements.
>
>Anyway, I think you know better what the implications are one way or 
>another.
> In the mean time I'll go build a font, such that Jonathan can take a 
>look at implementing it in Firefox.
>
>behdad
>
>> SVG implementations that support HTTP must support these encodings 
>> according to the HTTP 1.1 specification [RFC2616]; in particular, the 
>> client must specify with an "Accept-Encoding:" request header 
>> [HTTP-ACCEPT-ENCODING] those encodings that it accepts, including at 
>> minimum gzip and deflate, and then decompress any gzip-encoded and 
>> deflate-encoded data streams that are downloaded from the server.
>> When an SVG viewer retrieves compressed content (e.g., an .svgz
>> file) over HTTP, if the "Content-Encoding" and "Transfer-Encoding"
>> response headers are missing or specify a value that does not match 
>> the compression method that has been applied to the content, then the 
>> SVG viewer must not render the content and must treat the document as 
>> being in error.
>> 
>> http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers
>> 
>>> As there are only one current implementations and the format is 
>>>backwards compatible, it was recommended on the mailing list by 
>>>Sairus to keep the table version number to the current number.
>> 
>> Yes, I think that makes sense; because arguably implementations 
>> should have accepted this from the start. If they did not, they were 
>> non-conforming.
>> 
>> --
>> Best regards,
>> Chris Lilley, Technical Director, W3C Interaction Domain
>> 
>> 
>
>--
>behdad
>http://behdad.org/
>
>
>
>List archive: http://www.indx.co.uk/biglistarchive/
>
>subscribe: opentype-subscribe at indx.co.uk
>unsubscribe: opentype-unsubscribe at indx.co.uk
>messages: opentype-list at indx.co.uk
>
>

------------------------------------

------------------------------------

------------------------------------

Yahoo Groups Links

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20141029/9ec8fb0b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 125 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20141029/9ec8fb0b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20141029/9ec8fb0b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 126 bytes
Desc: not available
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20141029/9ec8fb0b/attachment-0002.bin>