Clarification of some aspect of opentype SVG spec

Tue Feb 16 17:23:14 CET 2016

Thank you Sairus!

All, 

please see attached the _final draft_ of the proposed changes and corrections. Some of the various comments collected in the document were forwarded to this AHG list after the discussions were held in various forums (in addition to this AHG list the comments were submitted via OpenType user list, "SVG in OpenType" W3C Community Group and from OpenType-layout group. This document summarizes the proposed changes.

IMPORTANT! Please review the proposed changes and respond to this list with your comments and objections. There has been one additional item added since the original draft sent on Feb. 12 (with changes highlighted). You have until the end of the day to respond with your comments and objections to any of the proposed changes, the silence is treated as approval!

If I do not receive any objections on the proposed amendment items I will upload the document as AHG input contribution tomorrow, Feb. 17.

Thank you very much for your contributions!,
Vladimir

-----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: Tuesday, February 16, 2016 10:58 AM
To: mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] FW: Clarification of some aspect of opentype SVG spec

Forwarding to the OFF list at Vlad’s request.

-----Original Message-----
From: Sairus Patel <sppatel at adobe.com>
Date: Friday, February 12, 2016 at 6:28 PM
To: "opentype-list at indx.co.uk" <opentype-list at indx.co.uk>, Hin-Tak Leung <htl10 at users.sourceforge.net>, "public-svgopentype at w3.org"
<public-svgopentype at w3.org>
Subject: Re: Clarification of some aspect of opentype SVG spec

>Hin-Tak,
>
>These are all great comments. Thanks for helping improve the spec.
>
>
>1. Compression. The spec says:
>
>> While SVG 1.1
>><http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers> 
>>requires 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.
>
>How about replacing "requires that conforming SVG implementations must 
>correctly support plain-text and gzip-encoded [RFC1952] data streams 
>only.”
>
>with:
>
>“requires that the SVG documents be either plain-text or gzip-encoded 
>[RFC1952]. The encoding of the (uncompressed) SVG document must be UTF-8.”
>
>Does that work?
>
>2. Encoding. See proposed wording above.
>
>3. Alignment, order and re-use of svgDoc: I don’t see reusing entire 
>SVG docs are being useful (multiple SVG doc index entries pointing to 
>the same svg doc), since each SVG doc contains an id=“glyph<gid>” so 
>reusing in that way doesn’t make sense (we want only one glyph 
>definition per glyph!). However, as Miguel pointed out, reusing within 
>an SVG doc makes total sense: this is SVG-in-OT’s way of 
>“subroutinizing.” In the extreme case, all glyphs will share a single 
>SVG doc (just as, for example, a single CFF contains all glyphs and any shared subroutines.
>
>I’m working on an actual SVG doc example and accompanying image to add 
>to the spec, since this would be really helpful. It will include an 
>example of sharing; for example to have glyphs 2, 3 & 4 share the same paths, say:
>
><svg>
>
>  <defs>
>    <g id="glyphToShare"> ...actual paths...
>    </g>
>  </defs>
>
>  <g id="glyph2”> 
>    <use xlink:href="#glyphToShare" />
>  </g>
>
>  <g id="glyph3">
>    <use xlink:href="#glyphToShare" />
>  </g>
>
>  <use id="glyph4" xlink:href="#glyphToShare" />
>
></svg>
>
>
>Miguel & I tested the approach above in Firefox’s impl & it works great.
>Note that glyphs 2 & 3 above can add additional elements to their <g> 
>if needed. This example may not squeeze into this round of comments 
>(the above is not a full-fledged, correctly formed SVG doc), but I’ll 
>have it out for review in a week or two & it will get into the spec 
>when it gets into the spec.
>
>Re. alignment, I think it was when we added cmap subtable format 14
>(UVSes) to the spec -- note its UINT24 data type -- that we dispensed 
>with trying to have 4-byte boundaries for data structures within new OT tables.
>(And of course CFF never had such an alignment model.) I don’t think 
>the lack of alignment warrants any specific note in the SVG table.
>
>Best,
>
>Sairus
>
>-----Original Message-----
>From: Hin-Tak Leung <htl10 at users.sourceforge.net>
>Reply-To: "opentype-list at indx.co.uk" <opentype-list at indx.co.uk>
>Date: Friday, January 29, 2016 at 10:17 AM
>To: "listmaster at indx.co.uk" <listmaster at indx.co.uk>
>Subject: [OpenType] Clarification of some aspect of opentype SVG spec
>
>>Message from OpenType list:
>>
>>
>>Hi,
>>
>>I think a call for addendum of the 2015 spec is up soon; in any case 
>>I'd like to mention a few things about SVG in opentype that I thought 
>>about, while adding SVG functions to Microsoft Font Validator in the 
>>past few weeks.
>>
>>- compression: The wording in the OT spec is a bit vague - SVG itself 
>>supports gzip and deflate delivery and the OT spec says only gzip is 
>>required for compliant implementation. I think bare deflate stream is 
>>a bad idea in OT - can we be a bit more explicit about avoiding it?
>>
>>- encoding: I added support to UTF16/UTF32 both endian and utf8. But I 
>>imagine one day somebody will want random favorite encodings of theirs 
>>for their XML, just because it isn't disallowed. Can something be said 
>>about that? Actually supporting UTF32 already seems overkill, since 
>>presumably most want to optimize for data size, so utf8 would be the 
>>best choice.
>>
>>- alignment, order and re-use of svgDoc: all the ones I have seen so 
>>far are contiguous (i.e. The next svgDoc starts exactly where the last 
>>one finishes), in order (svgDoc's are stored exactly in the order as 
>>listed in the index), and no re-use. I don't see a reason for re-use, 
>>but some drafts and earlier proposals mentions that. Also, the rest of 
>>OT specs tend to align to 4-byte for any sizeable structure so I was a 
>>bit surprised when I looked at the first font for clarifying this in 
>>actual use. A few words can be added about alignment, order and re-use.
>>
>>Hin-Tak
>>
>>
>>
>>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
>>
>>
>

------------------------------------
Posted by: Sairus Patel <sppatel at adobe.com>
------------------------------------

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

Yahoo Groups Links

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 368 bytes
Desc: m37774-ProposedAmendmentItems_OFF.doc
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20160216/d7e89b42/attachment.bin>