RE: A single, structured SVG doc - with offsets

If the only thing missing from #1 is sharing, why not simply add another table for any/all shared stuff.

Then when the parser/renderer is loading the glyph, it starts by parsing the shared data (if present) and then the glyph itself.

Leonard

-----Original Message-----
From: Sairus Patel [mailto:sppatel@adobe.com] 
Sent: Tuesday, February 07, 2012 7:15 PM
To: public-svgopentype@w3.org
Subject: A single, structured SVG doc - with offsets

It seems we keep going back and forth between the following models:

1. Each glyph definition is a self-contained SVG document. (Sharing: none. Subsetting: easy. Getting to a glyph: easy.)

2. All glyph definitions are in a single SVG document. (Sharing: possible. Subsetting: complex. Getting to a glyph: requires parsing entire document up to the glyph.)

We keep going back and forth because there are compelling advantages to each model.


I'd like to explore a different kind of model wherein all glyph definitions are still in a single SVG document, but that document has a simple structure, and some other OT table ('SVGO' - SVG Offsets, perhaps) provides key offsets into that structure, in the same way that 'loca' provides offsets into 'glyf' ('loca' is essentially an optimization only). The structure would be something like:

header
shared elements
element with id="g0"
element with id="g1"
...
element with id="g<numGlyphs-1>"
footer

This structure could enable easy glyph access and simplify subsetting, while allowing for shared elements. Even the shared elements section could be comprised of a list of elements each with a specific id (e.g. id="d<int>"), to aid subsettability. Not allowing glyphs to be nested within each other, for example, is not a limit on graphical expressiveness.

Note that there is still nothing font-like about this SVG document -- it contains no concept of glyphs, or Unicode characters, or ligatures. This is one of the goals of this whole effort: to use SVG's graphic, color and animation facilities only, and to have them be used in OpenType's font model.

I'm not involved enough in xml circles to know whether access to elements without parsing all the preceding data is an area which has been investigated much. Certainly this issue isn't specific to fonts.

Also, I don't know enough about how an SVG renderer works to know whether providing the glyph offsets-and-lengths to it would indeed allow it to access glyphs quicker.

However, imposing a simple structure to the SVG document, whether or not we have a separate offsets table, feels like the right thing to do. 

Any and all thoughts are welcome.

(I heard Mozilla had an intern that was exploring implementing some of this. Could s/he comment, if on this list?)

Thanks,

Sairus

Received on Friday, 10 February 2012 14:39:05 UTC