- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 28 Jun 2011 15:21:52 +1200
- To: Robert O'Callahan <robert@ocallahan.org>
- Cc: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>, "list.adam@twardoch.com" <list.adam@twardoch.com>, "www-font@w3.org" <www-font@w3.org>, "www-svg@w3.org" <www-svg@w3.org>, "www-style@w3.org" <www-style@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, OpenType List <opentype-migration-list@indx.co.uk>
Robert O'Callahan: > I'm quite enthusiastic about Adam's proposal! Me too, it seems to be a good way to get rendering of complex glyphs as you can do with the Full version of SVG Fonts and to have it support all the font features that many languages require. I think it’s also much simpler than the encode-OpenType-in-XML solution. Vladimir Levantovsky: > > Once the referencing mechanism is resolved, the OT glyph indices can be > > used to render corresponding SVG glyphs, if present, or the traditional > > glyphs as a fallback. I think you are right about the problem of assigning glyph indices based on the <glyph> element order. Perhaps that can be a default, but without being able to explicitly assign glyph IDs to each <glyph> then you’re not likely going to be able to just embed an existing SVG font document without rearranging it. Needing to write empty <glyphs/> just to match up to the glyph indices used in the font doesn’t sound workable. Using the <glyph glyph-name=""> attribute could work, or a new glyph-index="" attribute could be introduced. I don’t know whether that would be better than having a separate table mapping the <glyph>s to glyph indices. -- Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 28 June 2011 03:22:50 UTC