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

I know your method is designed to add to the current specs rather than
substitute it. But since there is a probability that some font vendors
might implement a full-on SVG solution if it’s made available—being
pretty attractive in terms of security—would it be helpful to do some
testing if the file sizes of SVGZ and WOFF-wrapped fonts would differ
and will impact performance (and how much)? Particularly under
different subsets.

–Bram


On Sun, Jun 26, 2011 at 4:11 PM, 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
>
>
>
>

Received on Monday, 27 June 2011 07:41:01 UTC