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

Dear list members of www-font,
as well as the cc'ed members of www-svg, www-style, public-webfonts-wg
and OpenType lists,

I'd like to share with you some thoughts regarding possible future of
SVG Fonts. At the end of this message, I'm formulating a proposal. I'd
like to start off a discussion and  stipulate some comments. I'd like to
suggest that the discussion should happen on the *www-font@w3.org* list,
which seems to be most appropriate at this point. But I'm cross-posting
this message to several discussion lists so that various people can form
their opinion.

1. INTRODUCTION

Obviously, SVG Fonts have some good and interesting concepts. One of
their advantages is that they can -- at least in theory -- freely
combine all aspects of SVG: multi-colored, multi-layered vector
graphics, and bitmaps.

However, SVG Fonts also have some serious drawbacks: while the glyph
definition using SVG is a great concept, all the other aspects of SVG
Fonts that make them work as a font, especially the character mapping,
access to alternate glyphs, and the layout behavior, are somewhat
under-defined and hard to implement. Therefore, it's rather unlikely
that at any time, all OS and application vendors will agree on a good,
full implementation of SVG Fonts.

Therefore, I'd like to suggest a different path: place an SVG Font as a
table inside of an OpenType font*, and combine the power of both formats.

*) By "OpenType font", I actually mean any font based on the SFNT
structure, that is OpenType, TrueType and Open Font Format.

2. SFNT STRUCTURE

The SFNT table structure that is the foundation of TrueType, OpenType
and OFF, is rather flexible. One of its greatest advantages is the
ability to host multiple sources for any given information, and have a
font engine prioritize which source to use.

For example, one and the same SFNT font can contain:
* the TrueType layout structure in form of a "kern" table which allows
basic line layout by providing the ability to do horizontal kerning
* the OpenType Layout structure in form of the "GSUB", "GPOS", "GDEF",
"BASE" and "JSTF" tables, which allows more complex line layout by
providing the ability to substitute alternate glyphs and perform
positioning in both x and y
* the AAT layout structure in form of "morx", "feat" and other tables as
defined by Apple, which also allows more complex line layout using a
different paradigm from OpenType
* the Graphite layout structure in form of tables defined by SIL, also
providing the possibility for complex and flexible layout

The SFNT table structure can include glyph definitions in either the
"CFF " or the "glyf" table, which describe monochrome outline glyph
definitions, but in addition to that, in can include ppm-specific glyph
bitmaps included in the "bdat/EBDT", "bloc/EBLC" and "EBSC" tables.

The font engine can decide which tables to proritize when doing layout
(so it can choose the AAT tables, in their absence the OpenType Layout
tables, and in their absence the TrueType layout tables). It can also
decide which tables to prioritize when producing rendered glyph images
(so it can choose the embedded bitmaps, and in their absence rasterize
the images from the outline descriptions).

This flexible, "cascading" structure has always been at the very heart
of all SFNT-based font formats.

3. A FONT INSIDE A FONT

Another characteristic of the SFNT structure is that out of the two most
popular outline description formats, the "CFF " table used by OpenType
is very peculiar. The data inside of the "CFF " table is in fact a
fully-functional font itself, stored in the Adobe Compact Font Format
(CFF). The CFF format not only includes glyph definitions, but also some
auxiliary data such as encoding, naming and other info, which makes it
quite usable. In fact, a CFF font can be converted to an Adobe Type 1
font, and back.

But when placed inside the SFNT structure in the "CFF " table, the CFF
font is only used as a glyph source. An OpenType font engine is supposed
to ignore the encoding and the naming information inside of the "CFF "
table, and is supposed to rely for the appropriate places in the SFNT
structure for that information: the "cmap" table for encoding, and the
"name" table for naming.

So what we have, is "a font inside a font", and the "internal font" is
only used for the most important information that it's been designed
for: to source glyph information written in 3rd degree curves.

4. A RUSSIAN DOLL

In fact, the embedding, or wrapping, goes even further if we consider
the WOFF format.

A Type 1 font is converted and compressed into a CFF font. The CFF font
is placed in the "CFF " table, and other tables are added to it ("name",
"cmap", the layout tables etc.) and an SFNT structure is formed. This
SFNT structure functions by itself as a desktop font. That structure is
compressed, and other data is added to it (metadata, private block etc.)
and a WOFF structure is formed.

So we have a system of containers such as: Type 1 -> CFF -> SFNT ->
WOFF. When rendering text, the application and the font engine perform
the reverse unwrapping: WOFF -> SFNT -> CFF and potentially the final
decompression to Type 1, and then rendering. At the process of wrapping,
additional data is added, and at the process of unwrapping, data is
extracted and used. For example the metadata retrieved while unwrapping
WOFF can be used to inform the user about the designer credits or
licensing terms, and the data retrieved while unwrapping SFNT is used to
perform line layout, to register the font in a font menu, and to provide
Unicode-to-glyph mapping.

5. SVG FONTS VS. SFNT FONTS

SVG Fonts currently have the advantage that they can provide flexible
glyph descriptions that can involve outlines and bitmaps, with multiple
layers, multiple colors and transparency. But they lack a well-developed
layout mechanism.

SFNT fonts have a well-developed mechanism (that including OpenType
Layout, but also the other layout mechanisms I've mentioned), but they
have rather simplistic glyph descriptions: outlines can be monochrome,
defined either using 3rd order curves ("CFF " table) or 2nd order curves
("glyf" table), and can be optionally supplemented by monochrome or
grayscale bitmaps.

So what would happen if those two solutions were combined? Combined in a
similar way that SFNT and CFF had been combined in OpenType. Since a
complete, fully-functional CFF font had been placed inside of the SFNT
structure, I believe that the same could be done with SVG fonts.

6. PROPOSAL

I propose that two new SFNT tables are created: "SVG " and "SVGZ". Each
of these tables could host a *complete SVG Font* as defined by the SVG
Font specification. Of course, those two tables should be mutually
exclusive in a font, similarly to the way in which "CFF " and "glyf" are
mutually exclusive. The "SVG " table would host an uncompressed SVG
Font, and "SVGZ" would host a compressed SVG Font.

Note that while "SVG " and "SVGZ" are mutually exclusive, they would not
be exclusive to "CFF " or "glyf". An SFNT font could exist that has all
the traditional properties of an OpenType font, with a "glyf" or "CFF "
table describing traditional outline glyphs, and with all the other data
such as OpenType Layout tables, Unicode-to-glyph "cmap" mapping table,
naming "name" table etc. But IN ADDITION to those tables, the font could
have an "SVG*" table (either "SVG " or "SVGZ") that would contain an
entire, fully-functional SVG Font.

Now, SFNT-based font engines that have no knowledge of the "SVG*" tables
would treat those tables just like any other unknown table: ignore it
(that's a mandatory requirement for any SFNT-based font engine).

But font engines that understood the "SVG*" table, could extract it, and
use JUST THE GLYPH DESCRIPTIONS contained in that font to render the
glyphs. They would not use any of the Unicode mapping, layout
information or naming included in the SVG Font (so that data could be
minimal or absent).

For naming and Unicode mapping, as well as for layout (including
alternate glyph selection, x/y positioning, complex script rendering
etc.), the font engine would use the appropriate SFNT-source information
("name" table, "cmap" table, OpenType Layout or AAT tables etc.). It
would be only for glyph rendering, i.e. rasterization, that they'd use
the glyph descriptions included in the "SVG*" table. This would be very
similar to the principle that already is in place for CFF fonts inside
of the SFNT structure.

The only requirement, really, would be that the order of glyph
descriptions in the embedded SVG Font would be exactly the same as the
order of glyph descriptions postulated by the SFNT font's glyph IDs
(used e.g. by the "cmap" table or the OpenType Layout table). Again,
same principle is true for CFF.

The font could include glyph descriptions only in the "SVG*" table, or
it could also include fallback glyph descriptions in either the "CFF "
or "glyf" table, and on top of that, it could even include embedded
bitmaps or any other glyph descriptions permissible by the SFNT
structure. It would be up to the font engine to decide on the priority.
Again, exactly the same principle is already employed when embedded
bitmaps are present: a font engine can use them or ignore them and go
straight to "glyf" or "CFF ".

And of course, as with embedded bitmaps, it would be up to the font
developer to make sure that the "SVG*" glyph definitions and the
fallback "glyf" or "CFF " glyph definitions for one and the same glyph
*somehow* correspond with each other. It would be up to the font
developer to provide "visually graceful" monochrome outline fallback for
the potentially full-color "SVG*" glyph descriptions.

7. CONCLUSIONS

What would we get from this? Since SFNT would be the principal wrapper,
we'd get all its benefits. And since the embedded font would be a full
SVG Font, we'd get all its benefits.

a) The sophisticated layout mechanism of OpenType Layout, AAT, Graphite
or any other existing, could be employed with the same code, the same
ease and the same flexibility, as this is the case today with "regular"
OpenType or TrueType fonts.

b) For font engines that are unaware of the "SVG*" tables, we'd get
graceful fallback and full backwards compatibility with existing font
engine implementations, renderers, tools, standards etc. The unknown
tables would just be ingored.

c) If this is deployed in a web browser which would chose to add the
extracted SVG Font descriptors to the document's DOM, it could do it
just as much as it would do so with existing implementations of external
SVG Fonts (I don't know if web browsers currently do that, but they
could). And through that, we'd get complete style-ability through CSS
and potential to modifications through JavaScript -- again, just like
with existing SVG Font implementations.

d) The contents of SFNT could be wrapped into WOFF and supplemented with
the same metadata as any WOFF would.

e) Since this is SFNT: if a desktop application or even OS chooses to
include an SVG renderer (e.g. Inkscape, Adobe Illustrator, and probably
many more), those fonts could be used as desktop fonts.

f) No new standards would need to be set up, no existing standards would
need to be modified.

g) Very little code would need to be written or modified -- mostly
"gluing" code. The only code that would matter would be to make sure
that the layout, naming and character mapping behavior would be
controlled by the SFNT-based font engines, and ONLY glyph rendering
would be realized through the SVG renderer. And even if no code were
changed at all, the gracefull fallback would still kick in and nothing
would break.

I think this is a rather sensible proposal with many advantages and very
few potential drawbacks (I cannot think of any off the top of my head).

Therefore, I'd like to ask for your opinions, comments etc. Just as I
suggested at the beginning, I'm proposing to hold the discussion on the
*www-font@w3.org* list -- but of course I won't mind if you choose to
use the other lists for that instead.

Best regards,
Adam Twardoch

Received on Sunday, 26 June 2011 10:42:27 UTC