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

Adam,

It seems to me that the main point of this is to gain support for
multi-colored glyphs, plus secondarily other cool things one can do with
full-on vector graphics, such as fill patterms and other effects. The cost
of doing so is support of SVG outlines in font specs and significant
complication for implementers—though in a neatly modular way.

I must say that although the encapsulation of CFF within SFNT in OpenType is
very neat and tidy in some senses, I think everyone involved closely with
that format recognizes that it was a bit of a hack done for expedience and
compatibility with existing tools and data flows such as PostScript
printing. Frankly, the duplication of certain kinds of information between
the CFF and other tables of the SFNT structures in OFF/OpenType is one of
the weak points of the format, and I can attest that this weak point has led
to problems and bugs for font and app developers.

The strength of the desires to include both TrueType and PostScript outlines
in one structure and to end the "font wars" arguably made that a worthwhile
compromise at the time. I'm not convinced that the needs here are strong
enough to make the downside of further data duplication worthwhile.

The prospect of having more than one set of vector outlines in a single font
is particularly perturbing to me, both in terms of the chances of things
going wrong leading to incompatibilities between the two sets of outlines,
and in terms of font size. At the same time, I recognize that in all
likelihood, if your objective is multi-colored vector fonts, such an
approach may be the only practical way to get there.

Regards,

T

On Sun, Jun 26, 2011 at 3:41 AM, Adam Twardoch (List) <
list.adam@twardoch.com> wrote:

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


-- 
“Puritanism: The haunting fear that someone,
 somewhere, may be happy.”
 —H.L. Mencken