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

Fri Nov 21 17:55:34 CET 2014

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/