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

Fri Nov 21 21:46:45 CET 2014

Thanks Vlad.  Here's an updated text based on your and Chris's feedback:

Under 2.2.3 SVG Document Index Entry, before the last paragraph ("For further
details about the content of the SVG documents..."), add:

"""
While SVG 1.1 requires [0] in addition to plain text encoding that conforming
SVG implementations must correctly support gzip-encoded [RFC1952] and
deflate-encoded [RFC1951] data streams, this specification requires that
conforming SVG implementations must correctly support plain-text and
gzip-encoded [RFC1952] data streams only. In both cases, svgDocLength encodes
the length of the encoded data, not the decoded document.
"""

[0] http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers

On 14-11-21 08:55 AM, 'Levantovsky, Vladimir'
vladimir.levantovsky at monotype.com [mpeg-OTspec] wrote:
>  
> 
> Thank you Behdad.
> I have adopted your suggested language with one minor editorial change - for
> svgDocLength description I would like to change the beginning of the last
> sentence to read "In both cases, ..." specifically referring to only two
> possible options of either plain-text SVG or gzip compressed SVG content. Any
> objections?
> 
> Thanks,
> Vladimir
> 
> 
> -----Original Message-----
> From: Behdad Esfahbod [mailto:behdad.esfahbod at gmail.com] On Behalf Of Behdad
> Esfahbod
> Sent: Thursday, November 20, 2014 9:25 PM
> To: Levantovsky, Vladimir; Sairus Patel; mpeg-OTspec at yahoogroups.com; Cameron
> McCormack; Chris Lilley; public-svgopentype at w3.org
> Subject: Re: [OpenType] Re: [mpeg-OTspec] SVGZ in SVG+OpenType
> 
> As promised, here's the proposed addition to the SVG_in_OpenType spec. Under
> 2.2.3 SVG Document Index Entry, before the last paragraph ("For further
> details about the content of the SVG documents..."), add:
> 
> """
> While SVG 1.1 requires [0] that conforming SVG implementations must correctly
> support gzip-encoded [RFC1952] and deflate-encoded [RFC1951] data streams,
> this specification requires that conforming SVG implementations must correctly
> support plain-text and gzip-encoded [RFC1952] data streams only. In any case,
> svgDocLength encodes the length of the encoded data, not the decoded document.
> """
> 
> [0] http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers
> 
> Cheers,
> behdad
> 
> 
> 
> On 14-10-29 09:55 AM, 'Levantovsky, Vladimir'
> vladimir.levantovsky at monotype.com [mpeg-OTspec] wrote:
>>
>>
>> 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
>>
>>
> 
> -- 
> behdad
> http://behdad.org/
> 
> 

-- 
behdad
http://behdad.org/