RE: specification for Mozilla's SVG in OpenType proposal

Rob, Cam,

> But it became clear during the project that supporting multiple documents each containing one or more glyphs would be negligible extra work

Such findings from actual implementations are valuable. Having multiple SVG docs each defining one or more glyphs reminds me somewhat of multiple font dicts within a single CID font, each one having its own specific hinting information (Latin glyphs are hinted differently from kana glyphs, for example). The parallel with SVG in OT might be groups of glyphs sharing common graphics elements. And as you point out it might have the benefit of being a poor man’s way of roughly subsetting the font (a point I hadn’t thought of before).

I think the main objection to a multiple-SVG-docs approach, I believe from someone at Mozilla, had been the issue of different timelines. With one SVG doc there is only a single timeline. But I see that the Mozilla proposal has something about coordinating timelines.

Looking forward to the live discussion (in about an hour!),

Sairus

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Wednesday, February 06, 2013 3:30 AM
To: Sairus Patel
Cc: Cameron McCormack; public-svgopentype@w3.org
Subject: Re: specification for Mozilla's SVG in OpenType proposal

On Wed, Feb 6, 2013 at 9:49 AM, Sairus Patel <sppatel@adobe.com<mailto:sppatel@adobe.com>> wrote:
At first glance, this proposal seems to have been developed with no reference to the discussions that have been taking place on this list re. various design decisions.

For example, one of the first design decisions was whether all glyphs were to be represented in a single SVG doc, each glyph in its own doc, or a hybrid or chunking approach (multiple SVG docs each containing one or more glyphs). I recall the consensus being the first option, and this was reflected in the Adobe draft proposals. However, Mozilla's proposal uses the third option. Is this a deliberate choice and preference, or simply the way Mozilla's implementation happened to have done it, unaware of (or perhaps predating) discussions on this list?

We were aware of some of those discussions. I actually took part in some of them. In fact we started our implementation assuming there would just be a single document containing all glyphs. But it became clear during the project that supporting multiple documents each containing one or more glyphs would be negligible extra work, and would potentially address more use cases, so we switched to that.
Another example is the proposed new glyphchar attribute. This goes against the principle that the SVG glyph descriptions are purely graphical, and that all semantics and metrics are to be taken from the usual OT tables ('cmap', 'hmtx', etc).

As Cameron said, "glyphchar" does not affect the processing of OT tables. It's just an alternative way to specify the glyph ID for an SVG element that's more convenient in some cases.
So this proposal seems to have taken the discussion back to the drawing board in at least a couple of ways. This is fine if reasons are offered that weren't discussed before, but I don't see any.

I think the changes/differences are really very minor.

Rob
--
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]