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@users.sourceforge.net>
Reply-To: "opentype-list@indx.co.uk" <opentype-list@indx.co.uk>
Date: Friday, January 29, 2016 at 10:17 AM
To: "listmaster@indx.co.uk" <listmaster@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@indx.co.uk
>unsubscribe: opentype-unsubscribe@indx.co.uk
>messages: opentype-list@indx.co.uk
>
>

Received on Saturday, 13 February 2016 02:29:24 UTC