Re: specification for Mozilla's SVG in OpenType proposal

On Fri, Feb 8, 2013 at 10:11 AM, Sairus Patel <sppatel@adobe.com> wrote:

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

The main thing we were thinking about is how to support large fonts (e.g.
10,000 glyphs) efficiently, which is needed for emoji, especially on
memory-limited devices. Putting all glyphs in a single document would
require instantiating one extremely large SVG document to draw even a
single glyph, which seems infeasible. On the other hand putting each glyph
in its own document seems like it would create a lot of unnecessary
overhead for other cases, such as a simple Latin-1 font where you expect
most glyphs to be used, or fonts where SVG resources could be shared by
multiple glyphs if they were in the same document. Allowing any number of
SVG documents, and providing flexible mapping of glyphs to documents, lets
font authors choose among these tradeoffs for themselves on a per-font
basis. That seems worth having given it's easy to implement.

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

I wonder if we should try to leave the timelines unspecified (unlike in the
current proposal where they are specified). I normally wouldn't suggest
leaving anything unspecified but the problem is we like to be able to share
font data across documents as much as possible. It is very difficult for us
to render a single SVG document in multiple contexts with different
timelines simultaneously, so when a font is loaded in multiple contexts
we'd have to give up on sharing font data for documents with animation. And
that seems unfortunate since I expect most cases of SVG font animation will
be simple looping animations where it doesn't really matter where you start
in the loop.

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]