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

On 29 jun 2011, at 10:03, Erik Dahlstrom wrote:

>  Out of curiosity I'd be interested in hearing if there are any other use-cases that would be helped by having script support in the font itself.

I can think of a number of things:

At line level: complex and conditional line layout. The stuff that's now exclusive to opentype GPOS and GSUB. While the different types of lookups address a wide range of typographic problems, they are no match for an actual script processing glyph records. Complex ligatures. Conditional alternating. Connecting scripts. Placing diacritics, vocalisation marks, processing cursive connections and slanted baselines. 

At the glyph level: conditional shapes, interactive shapes. Think of conditional scaling and dynamic proportions. This could work with or without caching the shapes. Or perhaps part fo the font's scripting is exposed to the DOM, "refresh", "poke" etc. Interpolation would be an interesting field. 

Being able to separate the characters (the actual unicodes) and the glyphs (how they appear on screen) would be an important step for SVG fonts. Using an actual scripting language rather than frozen data structures would allow the line and glyph shaping code to be relatively independent of implementations. As opposed to OpenType for instance. This means faster turnaround of ideas. 

For instance, imagine an SVG font has a js script on board, it could be a set of prenamed, well documented callbacks. SVG glyphs could have a glyphname attribute. A required "cmap" function would map unicode runs to a list of "glyphrecords" storing glyphname, xadvance, yadvance, xoffset, yoffset. Other functions with nicely structured but otherwise non-rigid names (exposed to the DOM and CSS) could perform some of the work of opentype layout features. These take a list of glyphrecords, and return the same list with modifications. Swap glyphs, insert glyphs, move stuff around.

Anyway, I write this as a type designer with an interest in technology. I understand there are many considerations of security, performance, complexity and efficiency that I'm ignoring for the moment. Obviously there are limits to resources and developer patience. But with a bit of focus, some conditional processing in the right place can go a long way. Fonts are programs and our languages need them to be flexible and smart. Let them run!

Erik

Received on Wednesday, 29 June 2011 10:31:49 UTC