FW: [OpenType] Update on color/animation in OT via SVG; new W3C Community Group

And here's an update I sent yesterday to opentype-migration-list@indx.co.uk:

-----Original Message-----
From: listmaster@indx.co.uk [mailto:listmaster@indx.co.uk] On Behalf Of Sairus Patel 
Sent: Thursday, October 27, 2011 10:57 PM
To: multiple.recipients.of.OpenType@inbound-smtp-1.adobe.com
Subject: [OpenType] Update on color/animation in OT via SVG; new W3C Community Group

Message from OpenType list:


1. *** Security ***

The security of the SVG elements was on my "Concerns" list the last time we discussed bringing color and animation to OpenType on the OT list, as you may recall.

Well, Cameron McCormack of the SVG WG pointed out an SVG editor's draft, "SVG Integration" <http://dev.w3.org/SVG/modules/integration/SVGIntegration.html>, which defines various modes SVG may be rendered in, and one of them, "secure animation mode," looks like it might be suitable for our purposes. It would allow declarative animation, disable script execution, and disable external references (which would cause network requests).

So our spec could say something like "The SVG glyph descriptions must be rendered in 'secure animated mode' as specified in the 'SVG Integration' document." Or we could specify some other mode with restrictions we deem more suitable.


2. *** How good would SVG look at small ppem sizes? ***

I brought this up today at the SVG WG Face-to-Face and the consensus was that the task of adding hinting or other facilities to raster well at small point sizes should belong to SVG, and should be done in the 'SVG ' table (or whatever it ends up being called) rather than adding new, separate bitmap tables to the sfnt.

This would benefit all SVG usage -- e.g. SVG used for icons on Web pages -- and not just SVG when used as glyphs in OpenType.

Bitmap tables at a variety of ppem's could be very large.

CSS media queries was mentioned as something to look into. The point was also raised that some OSes such as Mac OS dispense with fonts' hints altogether, so SVG not having a hinting mechanism shouldn't be seen as a blocker.


3. *** Options for the format of the 'SVG ' table: ***

a. An entire SVG <font> element, with <glyph> elements in it

b. A separate <svg> element for each glyph, accessed by an offset and length in the 'SVG ' table (Adobe Draft 1 posted to this list).

c. A single <svg> element container with clearly identified elements, e.g. <g> elements with unique id's corresponding to each glyph, but no <font> or <glyph> element present.

d. A "shared" chunk at the beginning, followed by a separate chunk for each glyph.

We don't want (a) since it involves SVG <font>s, a facility that has severely limited notions of encoding and glyph substitution/positioning, and a facility that seems to be on its way out in the spec world. We also don't like the fact that it involves data duplicated in other OT tables e.g. glyph widths or encodings.

Option (b) wouldn't allow glyphs to share data, and we'd have to mandate that the timeline be the same for each <svg> element, but the advantage of it is that each glyph would be treated as a stand-alone entity, which could avoid loading in all glyphs into memory.

Option (c) is attractive since it allows sharing between glyphs, but may mean that all glyphs would need to be loaded into the DOM at the same time.

We also discussed how we could allow static and animated versions of a glyph in one single element rather than specifying separate elements.
 

4. *** Parameterized colors in multi-color fonts? ***

Chris Lilley displayed some of the samples at http://www.handpaintedtype.com. We discussed possibly parameterizing the colors in SVG so that users would be able to select their own color components or select from color sets provided by the vendor. Definitely not a requirement right now, IMO, but we should design while keeping this in mind for the future.


5. *** New W3C Community Group ***

It was clear by the end of our discussion that the interface between the OpenType font engine and the SVG rasterizer would need to be considered in much more detail, since we want to specify something that can be efficiently implementable.

To this end, and to discuss other details related to this initiative on one forum (separate discussions have been happening on OT, w3 fonts, w3 svg, Typophile, etc), Chris created a w3c "community" to discuss this spec. Everyone is invited to join!

http://www.w3.org/community/svgopentype/ (some folks weren't able to access this URL today, BTW).


Best,
Sairus



List archive: http://www.indx.co.uk/biglistarchive/


subscribe: opentype-migration-sub@indx.co.uk
unsubscribe: opentype-migration-unsub@indx.co.uk
messages: opentype-migration-list@indx.co.uk

Received on Friday, 28 October 2011 15:26:20 UTC