[Fwd: RE: [OpenType] SVG Fonts inside of OpenType fonts? [Cross-post from www-font@w3.org]]

A contribiution to this discussion from Sairus Patel of Adobe, 
originally posted to the OpenType List and forwarded with his permission.

JH


-------- Original Message --------
Subject: RE: [OpenType] SVG Fonts inside of OpenType fonts? [Cross-post 
from www-font@w3.org]
Date: Mon, 27 Jun 2011 19:35:32 +0000
From: Sairus Patel  <sppatel@adobe.com>
Reply-To: <opentype-migration-list@indx.co.uk>
To: multiple recipients of OpenType

Message from OpenType list:


[I'm responding only to opentype-migration-list@indx.co.uk]

For quite a while now, Adobe has been discussing internally (and with a 
few external folks) a way to associate color/animation data with the 
glyph IDs in an OpenType font. (Unicode having encoded various emoji 
characters, for example, is a reason to associate such data with fonts.)

We’ve been thinking of an 'SVG ' table that is a basic (new) container 
format that associates chunks of glyph description data (SVG) with the 
glyph IDs in the font. There would be one chunk for static and one for 
animated (both optional), for each glyph ID in the font.

The container format could be applied to other "rich glyph descriptions" 
as well, for example a 'SWF ' table, perhaps maintained by a tag 
registry. So the table format would be identical (two chunks of glyph 
data, both optional, being able to be associated with each glyph ID).

When it comes time to render the glyphs, existing engines would use the 
existing CFF or glyf tables, but SVG-savvy engines could display the SVG 
snippets, when present.

cmap, hmtx and other glyph data would come from the usual OT tables, so 
there is no data duplication involved. Think of it as swapping SVG 
"charstrings" instead of a CFF or TT charstring at the very end of the 
layout process, for those clients who have implemented this facility.

Sairus

-----Original Message-----

Received on Tuesday, 28 June 2011 00:18:47 UTC