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

Hi Adam, all,

This is my attempt to provide a response to your proposal as well as some observations on comments submitted in prior emails (my personal opinion, FWIW).

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

Once the referencing mechanism is resolved, the OT glyph indices can be used to render corresponding SVG glyphs, if present, or the traditional glyphs as a fallback. The question is then whether it is truly necessary to embed the SVG data inside SFNT structure, or whether it would be sufficient to just reference an external SVG file containing glyph descriptions.

Karsten Luecke wrote:
> Ad 6.
>  > SVG and SVGZ
> I would suggest to require SVGZ and forget about SVG. SFNT usually
> holds binary data, and gzip (de)compression is not a big deal.
>
I agree with Karsten, *if* SVG data needs to be embedded I don’t see the reason to keep it uncompressed as part of SFNT file. Like Chris Lilley said, if the same SFNT file ends up being converted to WOFF, the SVGZ table would be kept as is.

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

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.

Thank you,
Vladimir


> -----Original Message-----
> From: public-webfonts-wg-request@w3.org [mailto:public-webfonts-wg-
> request@w3.org] On Behalf Of Adam Twardoch (List)
> Sent: Sunday, June 26, 2011 6:42 AM
> To: www-font@w3.org
> Cc: www-svg@w3.org; www-style@w3.org; public-webfonts-wg@w3.org;
> OpenType List
> Subject: 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 Monday, 27 June 2011 17:41:00 UTC