Re: [Devel] SVG & Fonts [was FreeType gzip support completed]

[David Turner]

Patrick wrote:
> Regarding this statement by David Turner:
> http://www.freetype.org/pipermail/devel/2002-November/004146.html
> ---
> "As far as I know, the SVG specification doesn't specify a specific font
> format, even if it is possible to define "glyph" elements, which are  
> arbitrary 2D shapes that can be used to display text in documents. These
> are however extremely big to define (SVG paths encoded in text), and do
> not include any hints or more sophisticated information."
> ---
>
> For clarification, with regards to the above post, when using SVG you
> can specify a font by:
> - Describing a font
>         - ie. specify family, size, style, etc. as per CSS2 spec
>         - http://www.w3.org/TR/REC-CSS2/fonts.html#font-properties
>         - so this could match any font that your system already has
>         in any format it can handle
>
Yes, but SVG is all about controlling precisely the output of your
documents (unlike HTML), which is why using "platform" fonts is not
going to work very well. As soon as your document uses a non-standard
font, chances that all your users will be able to see it as desired
rapidly converge towards 0, if you don't find a way to embed the
font within the document itself :-)

So, this "solution" is simply worthless for any serious user.

Same problem applies to PDF and Word documents (except that you
_can_ embed fonts relatively easily in these)


> - SVG Font
>         - ie. path/svg shape descriptions of the glyphs of a font
>         - http://www.w3.org/TR/SVG/fonts.html#SVGFonts
>
Yeah, makes your document grow to insane amounts, and lose all hinting
or advanced typographic capabilities with this. Only useful for simple
banner-like text, not for document presentation.

> - Web Fonts
>         - Downloadable fonts as part of the CSS2 specification.         -
> http://www.w3.org/TR/REC-CSS2/fonts.html#referencing
>
> With regards to the web fonts the CSS2 spec specifies:
> String                  Font Format                     Extension "truedoc-pfr" 
>               TrueDoc™ Portable Font
> Resource        .pfr
> "embedded-opentype"   Embedded OpenType               .eot
> "type-1"              PostScript™ Type 1              .pfb, .pfa
> "truetype"            TrueType                        .ttf
> "opentype"            OpenType, inc. TrueType Open    .ttf
> "truetype-gx"         TrueType with GX extensions
> "speedo"              Speedo
> "intellifont"         Intellifont
A _long_ time ago, the W3C organized a "www-fonts" commitee to
try to standardize "web fonts". Unfortunately, this never produced
anything useful, because each party had its own interests in mind:

  - font designers didn't want fonts to be disseminated easily
    through the web, even when in compact formats.
    (today, PDFs and Word documents routinely embed these, and
     nobody seems to complain much, or engage in vast piracy
     because of this)

  - font technology vendors (Adobe, BitStream, Agfa, Microsoft)
    all had their own "solutions" to the problem and didn't want
    a standard that meant, in essence, the end of their business

So, nothing came out of this discussion, except vibrant marketing
from vendors, and scared warnings from designers. That was probably
the least productive W3C project to date (though I've been said
that some recent "improvements" aren't that useful too ;-)

The CSS2 folks then simply decided that anybody could embed any font
in any format and call it "standard CSS2". Really great idea !!!

Now, what is the chance that *all* CSS2/SVG viewers will support
*all* these "standard" formats. 0 of course !! Instead, it's a
"let's the market decide" attitude which leads to the current
mess.

This means that the really "standard" formats will be determined
over time by what is best supported by the most widely used tools
and viewers.

My opinion is that this will be OpenType/CFF, or CEF (Compact Embedded
Fonts), a variation of it that Adobe already uses in its SVG Viewer.
You can really forget about TrueDoc/Speedo/Intellifont, these
technologies are going the way of the dodo when it comes to SVG.

And .eot (Embedded OpenType) is, as far as I know, the proprietary
format used by Microsoft to embed fonts in its Office documents,
as well as its Web Font Embedding tools. As far as I know, it's
basically Agfa's MicroType (i.e. loss-less compression of
OpenType/TrueType fonts), and will never be supported by FT2.
Just forget about it too :-)

> and instructs user agents to ignore unrecognized types. From the
> freetype homepage the list of supported formats is as follows:
>
>     * TrueType fonts (and collections)
>     * Type 1 fonts
>     * CID-keyed Type 1 fonts
>     * CFF fonts
>     * OpenType fonts (both TrueType and CFF variants)
>     * SFNT-based bitmap fonts
>     * X11 PCF fonts
>     * Windows FNT fonts
>     * BDF fonts (including anti-aliased ones)
>     * PFR fonts
>     * Type42 fonts (limited support)
>
> Between these two lists I was not sure whether or not Freetype supported
> embedded OpenType, TrueType w/ GX extensions, Speedo or Intellifonts. My
> research indicates that none of them are supported. Is that correct?
>
Yes, though you can use TrueType GX fonts, only the extensions will not
be used.

> Speedo and Intellifonts both appear to be defunct and never widely
> accepted.
>
Right, Speedo is the predecessor of TrueDoc/PFR. They compress well but
have relatively weak hinting.

> Embedded OpenType seems to be in competition with TrueDoc but
> both seem to be unused. NS6 seems to have dropped TrueDoc support and
> Mozilla doesn't seem to support it either based on tests at truedoc.com;

> however, Freetype lists support for it. Does anybody use downloadable
> fonts on web pages? Does anybody know of a free tool to create TrueDoc
> fonts? Since it seems unlikely that people would make complete font
> formats available for download in order to display their website, if
> embedded opentype and truedoc are both unused, that pretty much
> eliminates the downloadable portion of web fonts for practical use.
> Also, is TrueType GX effectively dead? Or does Apple support TrueType GX
> and OpenType?
The reason why FreeType supports TrueDoc is only to be used in the
digital TV market (where I currently work), where the format is a
requirement for certain international specifications like DVB-MHP.

That doesn't mean that the digital TV set-top-boxes should only
handle TrueDoc, only that they should at least support it. Since
BitStream has a patent regarding the *creation* of TrueDoc/PFR fonts,
it's clear that most people are going to send TrueType fonts
instead :-)

> ...
>
> Another comment made in the post I originally referred to was:
> ---
> "It may be possible that things changed a lot since 2001 regarding SVG,
> but I doubt about it. I also don't think that SVG has such a bright
> future, but that's a different story :-)"
> ---
>
> David, can you tell that "different story"? I would be interested in
> hearing your thoughts on SVG's problems.
Well, all I can publicly say is that SVG has a problem because it
tries to be too many things at once. I can cite SVG's good points:

  - it's XML-based, and that's very good

  - it has low-level graphics capabilities similar to that of PDF
    (like Apple's Quartz :-), without some of the stupidity from this
    format.

  - ideal to specify scalable graphics *images* (not documents)

Now, come the bad points:

  - much too many ways to perform styling. Reliance on CSS is _not_
    a good point (now, your SVG viewer needs a complete CSS2 parser,
    which happens to *not* be trivial to code, despite what every
    CSS proponents claims here, and I'm not even talking about CSS3)

  - text and fonts are second-class citizens in SVG, and this creates
    some problems when it comes to creating high-quality documents.

  - tries to be an animation language (like Flash), and a document
    structure language (like PDF), but falls flat in both cases. In
    other words, SVG is good for the software industry because it will
    require incredibly complex tools to produce any industrial-strength
    animation or document, when more focused and simple alternatives
    do exist.

  - tries to be a document structure language, when it should really
    be a document presentation language; inducing incredible problems
    that can only be managed through the other W3 creations
    (CSS, JavaScript, namespaces, XLink, etc...)

In other words, use SVG to edit scalable images. These SVG icons *are*
really cool :-). Avoid it if you want to generate large documents,
unless you're ready to waste buckets of money and time mastering some
un-needed complexity.

Anyway, I'm pretty certain that none of the available SVG Viewers today
support all of the W3 specifications (with the exception of Adobe, Batik
and all the TinySVG variants).

There are ways to make things easier. For example, I know some people
that use XSLT to translate documents into _simple_ SVG images on demand,
but the machinery behind this is quite impressive. Of course, they also
generate PDF documents on the fly :-)

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)