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

It seem to me that embedding an SVG font in it's entirety in a new table may
not be the right level to do this at. As I understand it, the problem is to
get colour animated glyphs in a font to enable support for things like
emoji. The original proposed solution was to embed a full SVG font with all
of it's features in a single table of an OT font with potentially all its
other tables. What seems to be missing is a way to have the SVG font
participate in the already existing rich support for layout in an OT font
that is already supported by a number of layout engines.

Instead of embedding the entire SVG font as a single blob wouldn't it allow
for better integration if the SVG font was broken apart into individual
glyphs and those then placed into a parallel glyph table similar to the
existing glyf table (say sglf). This sglf table would then be indexed using
an sloc table probably identical to the existing loca table except that it
refers to offsets in the sglf table.

Finally, to get from characters to glyph ids there would need to be a
parallel to the existing cmap table perhaps the scmp table. The scmp table
would also be identical to the existing cmap table with the tag difference
only to identify it as being in the svg glyph resolution chain. This could
be done without using a separate SVG cmap (scmp) but it would potentially
require a large sparse SVG loca table if you are adding only a small number
of SVG glyphs to an existing font with lots of TT outlines.

The dual chain (scmp -> sloc -> sglf and cmap -> loca -> glyf) would allow a
font to have both sets of glyph formats. Thus a font designer could build
fallback glyphs that could be displayed by layout systems that don't
understand the SVG format glyphs. It would also allow fonts to be built that
are mostly TT outlines with only some SVG glyphs. The fallback rules for the
use of the two chains would need to be defined to support this. For layout
systems that understand the SVG format glyphs they would attempt to find the
glyph in the SVG chain and if not found then they would fallback to the
standard TT outline chain. Systems that don't understand the SVG chain would
use the TT outline chain and get whatever is available there - perhaps only
the .notdef glyph.

The numbering space for glyph ids for both the SVG glyphs and the TT
outlines would be identical so that the SVG glyph would then interoperate
with all of the other TT/OT tables that refer to glyph ids. Integrating the
SVG glyphs in the above way would also allow them to be used by layout
systems in the same way as they do now including doing complex layout using
GSUB and GPOS since these SVG glyphs would have glyph ids as used in the
existing OT spec. Any tables in the TT/OT spec that use glyph ids would work
with the SVG glyphs.

Stuart

On Wed, Jun 29, 2011 at 8:20 AM, Adam Twardoch (List) <
list.adam@twardoch.com> wrote:

> I must admit that Vlad's post about the necessity for having a glyph
> index-based selection of glyphs in an SFNT+SVG solution because we don't
> want to force the font developer to provide SVG versions of all the
> glyphs (if we want to proceed with the "fallback" mechanism meaning that
> a "glyf" or "CFF " table would be provided along) made me think that my
> original proposal has some drawbacks.
>
> Obviously, my main principle behind proposing the solution was to come
> up with a format that is the simplest possible to implement. But now I
> realize that it's not just soooo simple to stick the entire SVG font
> into SFNT and not worry about anything else.
>
> So, let me reshape my main points as follows:
>
> 1. The most important motivation behind my proposal is to have the
> ability to have fonts which can use arbitrary colors, multiple outline
> layers, and include bitmaps. Perhaps also animation, if a client
> supports it (with the possible fallback of "first frame as static image"
> in non-animated context). I don't really care so much for the precise
> technical implementation, and my own implementation proposal was just
> input for discussion. I'm very glad that the discussion has emerged, and
> people have provided valuable feedback so far.
>
> 2. I do realize now that using ALL of the SVG Font inside of SFNT does
> create important problems: first, the glyph selection is not easily
> solved (except if we either provide an additional table or add
> attributes to the SVG glyphs). Second, there is significant overhead in
> the SVG Font spec which would need to be ignored by the client that
> implements SFNT+SVG.
>
> 3. One key thing that I've realized long ago is that in a way, these
> days the layout systems are more complex and more difficult to "get
> right" or implement that the glyph rendering. This is why I proposed
> this SFNT+SVG at all. I have a strong conviction that coming up with a
> completely new, XML-based format that would encompass all of a layout
> system's needs (alternative glyph selection, complex script support,
> mark attachment etc. etc.) would be a huge undertaking. Neither of the
> existing SFNT-based layout systems (OpenType Layout, AAT, Graphite etc.)
> are perfect, but they're all workable and well-tested. And we have tools
> to develop such fonts. So I believe it is only right to rely on them,
> i.e. build on the foundation of SFNT. It's the best that we have, we
> have it now, and an alternative is very unlikely to emerge anytime soon.
>
> 4. The above does not mean that all efforts should stop to come up with
> some mythical "Fonts 2.0" system that will supersede all that we've had
> so far. But before (if ever) we come up with this "egg-laying
> wool-milk-sow" (Eierlegende Wollmilchsau, a funny German phrase that
> could be approximated by "the Swiss army knife") of fonts, we need
> workable solutions. Those approaches are not mutually exclusive.
>
> All in all, I'm now more in favor of Adobe's proposal, which basically
> dissects the SVG Fonts into glyph definitions, and packs them into a
> more native SFNT form. Since we don't really need ALL of the SVG Font
> inside of SFNT, a format such as the one proposed by Adobe is probably a
> much better solution. And independent of this, people are of course free
> to follow the alternative path of expanding the SVG Font spec into a
> fully XML-based font format that is as strong in future with respect to
> text layout as it is now with glyph rendering. But as I said many times
> -- developing this is a song of future.
>
> In short: since Sairus Patel has already done the work of proposing a
> table format for SVG glyph definitions inside of SFNT, I support it.
>
> Best,
> Adam
>
>
>
>