Re: Web Fonts

On Tuesday 15 August 2006 11:21, David Hyatt wrote:
> Looking at the Web Fonts spec, it seems to me that it is way too
> complex right now (and that this is probably a significant reason
> that it hasn't seen more success in being implemented).

It's complex if you want all its functions: font download, font 
database, font substitution and font synthesis. But IE uses it for font 
download and Prince as a font database (in the sense of section 15.2 of 
CSS 2.1) and those functions aren't so difficult.

>
> Wouldn't it be sufficient to simply support the addition of URIs to
> font-family?  This would work properly with fallback, and thus could
> work in conjunction with installed fonts on the system, and the URI
> could be to a zip file that contained all the variants of a font as
> well if needed.

We had a discussion[1] about this a few months back. There was no clear 
conclusion, I believe, so it's good that the discussion continues. But 
the question of syntax seems to be part of a wider issue.

The original observation was that "image replacement" techniques are 
most often used to replace text by an image of text in a specific font 
and it seems Web Fonts, if they had been available, would make probably 
80% of image replacement unnecessary. Web Fonts would be easier for the 
designer and more accessible for the reader. So why aren't they 
implemented?

There was another question, which may become important if the answer to 
the above involves syntax changes: CSS3 will make image replacement 
itself as easy as a single property, viz., 'content', but then the 
question becomes if there is a need to link image replacement and 
fonts, so that the image replacement can act as a fallback when a font 
isn't available.

As for the first question, possible reasons that Web Fonts are 
implemented so poorly (only one Web browser on one platform, and for 
the rest only in SVG viewers):

   a. Syntax not attractive enough
   b. Implementation is difficult
   c. Lack of rights management
   d. Security problems (fonts containing malicious code)
   e. Lack of tools for authors to create downloadable fonts
   f. more?


Ad a: The indirection through @font-face is seen by some as a threshold 
that may be too high. The minimum to write would be

    @font-face {
        font-family: Headline;
        src: url(http://example.com/fonts/hdl);
    }
    ...
    h1 {font-family: Headline, serif}

On the other hand, when you use the same downloadable font also in other 
rules in the style sheet, the overhead becomes less.


Ad b: On some platforms it may not be possible to install new fonts or 
not possible to install them for one process only. However, I think I 
heard implementers say (they can correct me if I'm wrong) that there 
are sufficient platforms where it *is* possible (Windows, Mac, 
Unix/X...), even if the restriction to one process is by convention 
only and cannot be enforced. The real implementation problems seem to 
be c and d.


Ad c: There are by some estimates around 500 free fonts available, in 
the sense that you can redistribute them freely. But many are of poor 
quality, others only cover a very small range (only ASCII, or even only 
uppercase ASCII). There are certainly useful fonts among them (I've 
used some in presentations I've given), but maybe too few to make it 
worthwhile to implement @font-face.

There are also many fonts that may be "embedded" in documents, but the 
way the 'src' descriptor works requires the "embedded" font to be 
downloadable at a certain URL. Copy-pasting that URL from a style sheet 
into something else is so easy, it can hardly be seen as a conscious 
effort to steal a font.

Microsoft has developed a solution for that: its EOT[2] format is a 
variant of OpenType that embeds in the font file the list of documents 
(URLs) the font may be used with. So now if you download the font and 
want to use it for another document, you have to actually modify the 
font file, which is (for most people, I think) a clear enough sign that 
you are breaking a license.

The problem with EOT is that it is proprietary and that it leads to 
problem e, lack of tools. So maybe we need a standard format that does 
what EOT does: associate in one file both the glyph outlines and the 
URLs of the documents they may be used with. (Note that it is not a 
copy-protection technique in the sense of making it difficult to copy 
the font, it just makes it easy for people to "do the right thing," 
i.e., embed rather than redistribute.)

There are also many fonts that may not even be embedded. They may only 
be used on one machine. The question there is why that is the case. Did 
the font designer simply forget to tick the "embeddable" check box in 
his drawing program? Did he consciously uncheck it because he believes 
current implementations (such as the EOT format) provide insufficient 
protection? I don't have any answers to this question, but it may be 
worthwhile to lobby with font designers to allow embedding of their 
fonts.


Ad d: Modern font formats such as OpenType contain little programs that 
are executed by the font rasterizer. In principle, that code is limited 
to computing the shape of a glyph, but as always, some interpreters may 
suffer from buffer overflows and similar bugs and indeed there have 
been cases of fonts being used to break into systems.

When a font comes as part of a Web page, the user has no idea it is 
being installed. So how to ensure the font is safe?

Of course, if a font crashes a system, it is first of all a bug in the 
system and it should be fixed. I don't know how real this problem still 
is and how difficult it would be to protect against it, maybe with some 
form of sandboxing.


Ad e: Fonts on the Web are very often distributed as ZIP files and those 
ZIP files often contain more than one font (e.g., roman, italic, bold 
and bold-italic faces of one family). Current implementations of 
@font-face don't handle such ZIP files, so an author has to do a bit of 
work to unzip and upload the individual font files.

If fonts are only licensed for embedding, you need to use EOT, which 
requires running a program, WEFT, which is only available on Windows.

You may also want to subset a font, to eliminate glyphs that you don't 
need and make the file quicker to download.

CSS could be enhanced to allow ZIP files directly (or in general 
downloads of multiple fonts from one URL), but subsetting and embedding 
still require some work from the author.


As for the other question, whether to make image replacement dependent 
on fonts, the WG decided to try the following in the next draft of 
Generated Content:

    h1#main { content: require-font(Zapfino) content, url(main1.png) }

which should be read as: if the font Zapfino is available display the 
element's content normally, otherwise display the image. (Note that it 
doesn't say to use Zapfino, that's the task of 'font-family'.)

This syntax only works with font names so far, not with URLs.


In conclusion:

It is currently not clear that allowing an alternative, shorter syntax 
(viz., a URL in the 'font-face' property) will significantly increase 
the use of downloadable fonts. Providing a fallback for failed font 
downloads in the form of image replacement and providing some form of 
DRM may be more important.


[1] http://lists.w3.org/Archives/Public/www-style/2006Apr/0070.html
[2] http://www.microsoft.com/typography/web/embedding/default.htm


Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 18 August 2006 16:36:37 UTC