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

Fri Nov 21 03:24:30 CET 2014

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/