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

On 11-06-26 19:32, Thomas Phinney wrote:
> 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.
>
Thomas,

of course, I'm thinking in practical terms here. Certainly, there would
be some challenges in getting this done, but we'd have great benefits.
All the alternative approaches, such as proposals to define an XML
representation of OpenType Layout tables, or extending the SVG Font spec
even more to cover all kinds of layout commands, are, IMO, completely
out of the question. After all, there have been attempts to make that
happen (XML format to express SFNT tables), and they've never reached a
stage beyond being usable as debugging/reporting format. As some people
say, TTX is an undocumented format, primarily because documenting it
would create the necessity of keeping it in sync with the relevant SFNT
specs (TrueType, OpenType, OFF). And on top of that, discussing this
would open up an ENDLESS case for discussions on how to express SFNT
data "properly".

UFO and the Adobe FEA format (used by UFO2, and other implementations)
serve a different purpose: they're not set up as deployment formats, but
rather as development formats. Because of this nature, the number of
potential implementations is vastly smaller, and the specs for those
format can be revised on a more timely, consensus-based manner. The
actual cost of revising implementations to match these changes is
relatively small. There will never be more than a dozen implementations
of UFO or AFDKO, and actually the real number of active implementations
will always be more like 4-5, all controlled by small entities (groups
within larger companies or actual companies or individuals). To make a
change in UFO or AFDKO, it doesn't take a committee of 50 people to
debate for a year -- but for anything that goes to wide deployment, that
is the case.

In fact, my proposal doesn't even "require" anybody to agree. As a font
developer, I could just start putting an "SVG " table into any fonts,
and convince an independent font tools vendor such as Fontlab Ltd. to
support it within its limited scope of applications. And at any time, I
could keep trying to convince other parties to add support for it as
well. Start with one browser (say, Mozilla), plus one smaller company
(say Prince XML), and then contribute some code to some opensource
project (say Cairo), and you've got the ball rolling.

I'm not saying that I'll do it regardless of the community opinion --
because that would be silly.

I pretty much well know that in an ideal world, this proposal should be
replaced by something "ultimately better". But the same is true for
OpenType etc. Yes, there are complications involved in getting the
support of OpenType right (and CFF was certainly one problem child). But
that's what we've got to work with. Therefore, rather than proposing a
completely new format (say, a "clean" SFNT table that deals with
multi-color, multi-layer, vector-based, mixing bitmaps etc.) stuff, I
think my proposal is quite sensible:

1. It relies on existing specs, and to some extent, implementations. Of
course there probably are no complete implementations for the full SVG
Font spec, but my guess is that to some extent the reason for this is
that SVG Fonts do not include support for the minimum set of things that
a modern font format requires (i.e. sensible support for complex scripts).

2. It does not *force* any vendor to support the new table, because of
the fallback mechanism to glyf/CFF. An OpenType+SVG font will work as a
regular OpenType font as well. And I think this is the actual real
beauty of what I'm proposing. The beauty of SFNT is that I can stick
anything into it, and all implementations already are made in such a way
that they ignore the unknown tables. That's one nice side-effect of the
TrueType-OpenType dual approach. From the very beginning,
implementations had to be made aware of the existence of potentially
unknown tables (Apple had to ignore "GSUB" or "GPOS" in Mac OS X 10.3,
Microsoft had to ignore "morx" or "feat", and so had Adobe or other
implementations).

This particular behavior HAS BEEN TESTED. And actually, it's exactly
THAT FACT that makes this proposal workable -- even though it's far from
an ideal solution. :) Because from what I've learned from working with
software over the years, one of the most important aspects of a format
or protocol, and its implementations, is that they don't "choke" on
unknown chunks of data. There are lots of formats or implementations
that do -- i.e. they don't have proper "graceful fail" mechanisms in
place. Those "poor" formats or implementations make too many positive
assumptions about what they're about to receive. But SFNT
implementations have actually been "good" in this respect from the very
beginning. Which makes SFNT a good format in this respect -- and
therefore a very suitable one for the kinds of extension I'm talking about.

Best,
Adam

Received on Monday, 27 June 2011 18:22:24 UTC