FW: Clarification of some aspect of opentype SVG spec

[Sairus Patel]

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
>>
>>
>