W3C home > Mailing lists > Public > www-svg@w3.org > June 2011

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

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>
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

 

Received on Monday, 27 June 2011 18:25:45 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:48 GMT