- From: Levantovsky, Vladimir <Vladimir.Levantovsky@MonotypeImaging.com>
- Date: Mon, 27 Jun 2011 14:25:03 -0400
- To: "list.adam@twardoch.com" <list.adam@twardoch.com>
- CC: "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>
On Monday, June 27, 2011 1:58 PM Adam Twardoch wrote: > > the glyphs in CFF are being identified internally using glyph names, > but these glyph names are not used to identify the glyphs from within > the other SFNT tables. It's just the ORDER of glyph definitions that > implicitly sets the glyph IDs. In SVG's case, it would be the same: all > SVG glyph definitions are set in a particular order (because it's XML, > and XML *is* a SEQUENTIAL format, rather than a random-access format). > So you don't need explicit numerical IDs: you just work on the same > assumption as with CFF, that the first glyph defined is "ID 0" in the > list, the second is "ID 1" etc. > Yes, I saw this in your proposal, but doing so would essentially require that every glyph represented in OT font would have to have its equivalent defined in SVG - rather wasteful and unnecessary IMO, even if we only have empty definitions to keep the count going. A practical alternative is only to have some glyphs defined using SVG, and map them to OT indices (e.g. by hacking a <glyph-name>). > > Another aspect that needs to be considered is font scale - I suspect > that for proper text layout that combines normal glyphs with SVG glyphs > - a generic font engine would have to be responsible to determine the > glyph scale since it would also take into account a font hinting data > (where appropriate). > I agree that this is not at all completely trivial. But that's already > given for any SVG Font renderers: if you use an SVG Font and a > character code appears in the text that isn't covered by the SVG Font, > then the browser or the OS takes care of font fallback using the CSS > Font stack and using OS font fallback mechanisms. So this technology > is already working, in principle. If the goal is to create a generic mechanism, then I don't think we should rely on presence of CSS to implement font fallback. My understanding (I might be wrong though) is that you wanted to create a generic format that is capable to handle animated / colored glyphs mixed together with the traditional glyphs in a single font. > Of course, interaction between various glyphs, > some sourced from the SVG table and some from the glyf or CFF table, > using OpenType Layout substitutions and positioning, would create some > challenges, but IMO they would be quite minor ones. Not sure I'd agree - if the goal is to do layout using a mix of traditional and SVG glyphs and produce the text of decent typographic quality ( by at least preserving metrics and positioning) - this could be quite a challenge. Thank you, Vlad
Received on Monday, 27 June 2011 18:25:51 UTC