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@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@yahoogroups.com [mailto:mpeg-OTspec@yahoogroups.com] On
> Behalf Of Sairus Patel sppatel@adobe.com [mpeg-OTspec]
> Sent: Wednesday, October 29, 2014 10:36 AM
> To: opentype-list@indx.co.uk; mpeg-OTspec@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@behdad.org>
> Reply-To: "opentype-list@indx.co.uk" <opentype-list@indx.co.uk>
> Date: Sunday, October 26, 2014 at 6:04 PM
> To: "listmaster@indx.co.uk" <listmaster@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@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@indx.co.uk
>>unsubscribe: opentype-unsubscribe@indx.co.uk
>>messages: opentype-list@indx.co.uk
>>
>>
> 
> ------------------------------------
> 
> ------------------------------------
> 
> ------------------------------------
> 
> Yahoo Groups Links
> 
> __._,_.___
> ------------------------------------------------------------------------------
> Posted by: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotype.com>
> ------------------------------------------------------------------------------
> Reply via web post
> <https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1242;_ylc=X3oDMTJxdGJycmNlBF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRtc2dJZAMxMjQyBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQxNDYwMTcyNA--?act=reply&messageNum=1242>
>  •  Reply to sender
> <mailto:Vladimir.Levantovsky@monotype.com?subject=RE%3A%20%5BOpenType%5D%20Re%3A%20%5Bmpeg-OTspec%5D%20SVGZ%20in%20SVG%2BOpenType>
>  •  Reply to group
> <mailto:mpeg-OTspec@yahoogroups.com?subject=RE%3A%20%5BOpenType%5D%20Re%3A%20%5Bmpeg-OTspec%5D%20SVGZ%20in%20SVG%2BOpenType>
>  •  Start a New Topic
> <https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/newtopic;_ylc=X3oDMTJmNW5xY3J2BF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0MTQ2MDE3MjQ->
>  •  Messages in this topic
> <https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/topics/1241;_ylc=X3oDMTM1OGppdjIxBF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRtc2dJZAMxMjQyBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQxNDYwMTcyNAR0cGNJZAMxMjQx>
> (2)
> 
> Visit Your Group
> <https://groups.yahoo.com/neo/groups/mpeg-OTspec/info;_ylc=X3oDMTJmY2x0NDM4BF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0MTQ2MDE3MjQ->
> 
> 
> Yahoo! Groups
> <https://groups.yahoo.com/neo;_ylc=X3oDMTJlaWVtN20wBF9TAzk3MzU5NzE0BGdycElkAzEyODYwOTU1BGdycHNwSWQDMTcwNjAzMDM4OQRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQxNDYwMTcyNA-->
> 
> • Privacy <https://info.yahoo.com/privacy/us/yahoo/groups/details.html> •
> Unsubscribe
> <mailto:mpeg-OTspec-unsubscribe@yahoogroups.com?subject=Unsubscribe> • Terms
> of Use <https://info.yahoo.com/legal/us/yahoo/utos/terms/>
> 
> .
> 
> __,_._,___

-- 
behdad
http://behdad.org/

Received on Friday, 21 November 2014 02:24:59 UTC