W3C home > Mailing lists > Public > www-style@w3.org > August 2006

Re: Web Fonts

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Fri, 18 Aug 2006 16:10:02 -0400
Message-ID: <44E61E9A.1090409@earthlink.net>
To: Bert Bos <bert@w3.org>
CC: www-style@w3.org

Bert Bos wrote:
> 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

   Possible. Perhaps something like this...

| h1 { font-src: url(http://example.com/fonts/hdl); }

   I tend to agree that using @font-face is better if you're using large
numbers of fonts, but if you're using them for something like a single
header, it's a pain. Then again, web development may eventually handle
this well enough that it isn't a problem.

   Either way, I don't like simply "src". It's to generic when
referencing what is specifically a font URL.

>    b. Implementation is difficult

   I suspect this actually ties in with problem "e", because the best
reason to prevent font installation is that the code in the font could
be a trojan. Considering that support for new fonts would not be
difficult to implement on most systems, it doesn't seem like something
that should be blocking.

>    c. Lack of rights management

   Since people can already pirate fonts and create images from them to
use on their websites, I don't see the issue. Are we to believe that
people who pirate fonts are huge accessibility fans?!? Or are we trying
to create some big DRM scheme for every file referenced by CSS?

   Furthermore, we need to ensure that a compliant implementation of CSS
can be written as open source. If you can figure out how to do DRM in a
GPL project, good for you, but I suspect the best thing would be to
simply leave support for specific font formats up to the implementors.

>    d. Security problems (fonts containing malicious code)

   It's an issue, but I see it as being an issue related to supporting
specific file formats, and as such I feel it's outside the scope of CSS.
Implementors should determine what security model they need to use
rather than waiting on an elaborate security specification from a
working group that isn't necessarily security oriented.

>    e. Lack of tools for authors to create downloadable fonts

   This would mostly seem to be a problem with OpenType fonts, which
tend to be in the hundreds of kilobytes. Many of the fonts I have on my
system are simple TrueType fonts that are only a few kilobytes in size.
So some font files could be downloaded without compression, while some
will remain huge even with compression. This is similar to situations
with image formats, where some file formats are better than others when
file size is an issue. I suggest that we just forget about compression
entirely and let the best font format win.

>    f. more?

   Aural fonts? Support for a profile of SVG as a font format? Ability
to use large bitmaps as font files?

   Support for the Starcraft FNT format? ;)

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

   I was under the impression that only Microsoft supported downloadable
 fonts, and only via a proprietary format that requires a conversion
utiltiy. So the issue seems to be the number of implementations that
support common/open font formats, not how difficult it is for the
authors to use.

> Providing a fallback for failed font 
> downloads in the form of image replacement and providing some form of 
> DRM may be more important.

   Fallback is important. DRM should be handled in the file format.
Received on Friday, 18 August 2006 20:10:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:46 GMT