RE: SVG Fonts inside of OpenType fonts? [Cross-post from [email protected]]
"Levantovsky, Vladimir" <[email protected]> Mon, 27 Jun 2011 14:25:03 -0400
| Newsgroups | gmane.comp.web.css.general,gmane.comp.web.fonts,gmane.comp.web.svg |
|---|---|
| Message-ID | <7534F85A589E654EB1E44E5CFDC19E3D0BE7CF974C@wob-email-01.agfamonotype.org> |
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