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

On 11-06-27 19:40, Levantovsky, Vladimir wrote:
> In general, I agree that *if* a support for multi-colored / animated glyphs (such as emoticons) is needed, using SVG to define and render them is not a bad idea. However, Like Thomas Phinney already noted, combining two fonts "as is" to form "a font inside a font" isn't desirable, and in order to benefit from the existing OT/AAT/SIL layout options SVG glyphs would need to be referenced by using the same glyph IDs. This is exactly where the weakness of the SVG is - the glyphs inside SVG fonts are identified by the <unicode> strings and while this can be made to work for one-to-one and many-to-one mappings - it doesn't work for one-to-many mappings in a generic way. I think that at a minimum, SVG glyphs should have another attribute that would give each glyph a unique ID, which can then be used to map those glyphs with OT glyph indices (or an existing <glyph-name> attribute can be hacked to serve as a glyph index, e.g. by giving each glyph a numerical "name" that corresponds to its glyph index in OT font).
Vlad,

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.

> 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. 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. Other font combining
technologies such as the Composite Font mechanism that's being
discussed, or the CSS font stack, deal with the same challenges, so
they'll surely be addressed by font engine and text layout vendors one
way or the other.

> As far as WOFF is concerned, I don’t think we should create strong ties between WOFF and this particular proposal. If the purpose of this proposal is to extend the current capability of generic desktop fonts by enabling the use of multi-colored / animated glyphs in *any* application, then using WOFF as a container format isn't really a good idea because it was designed specifically as the webfont format. Extending SFNT structure would be all that's needed to accomplish the task.
I agree. I mean, WOFF is a flavor-neutral SFNT packaging format. Any
SFNT table can be placed in WOFF, and therefore, any "custom" table
(such as "SVG ") could be. So I don't intend to propose anything special
in WOFF to handle SVG, because if an SVG Font were placed in the SFNT
container, WOFF would automatically cover it. I just made a point of a
use case: if an SVG Font were an SFNT table, we could use all the same
SFNT handling (including packaging as WOFF), which would greatly
simplify things.

Best,
Adam

Received on Monday, 27 June 2011 17:58:48 UTC