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

Re: Downloadable fonts and image replacement

From: Dave Raggett <dsr@w3.org>
Date: Tue, 25 Apr 2006 15:32:06 +0100 (BST)
To: Bert Bos <bert@w3.org>
Cc: www-style@w3.org
Message-ID: <Pine.LNX.4.62.0604251404450.9071@localhost.localdomain>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 24 Apr 2006, Bert Bos wrote:

> Some of the issues under consideration
>
>    Downloadable fonts in general -
>      - Protecting font designers' IP (good fonts are labor-intensive)
>      - Security problems (fonts can contain executable code)
>      - Performance problems (download multi-megabyte CJK fonts?)
>
>    CSS syntax and functionality -
>      - Do we need other/better/shorter syntax?
>      - Interaction with other parts of CSS (e.g. font-style)
>      - Specifying archived (e.g. zipped) fonts
>      - Other functionality?
>
>    Fonts and image replacement -
>      - What if I want to use the image *only* if my special font cannot
>        be downloaded/is not installed on the user's system?
>      - Accessibility considerations for image-text replacement
>
> Discuss.

I recently tried embedding a GPL'ed font with my XHTML-based slides 
using the Microsoft EOT solution [1], which subsets the font to 
match the associated web page. I have now given that up due to the 
effort involved in having to update the EOT file each time I edited 
the slides. This gets worse if you want to embed the same font with 
other web pages. The very limited use of EOT files despite the very 
high market penetration of IE6 for Windows suggests that I am not 
alone with my experience.

I am therefore looking for support for direct use of TTF files so 
that I don't have to use a special tool for embedded fonts like Weft 
[1]. There are plenty of fonts with open licenses that are perfectly 
good for most purposes, so a DRM-based solution isn't high on my 
wish list.

Whilst using images for text can be very effective, it prevents 
reflow when the window size is reduced, and it is also a pain when 
the web page needs to be regularly updated. A widely supported means 
to use embeddable fonts with open licenses would be much 
appreciated. I would expect to see continued use of text in images 
for some purposes, although this would be reduced if it were easier 
to use SVG for combined text and graphics, e.g. for buttons and 
decorative headings. Browser support for using SVG as CSS
backgrounds would be very helpful in that regard.

Once you have gone to the effort of creating text in images, I
see little additional benefit from being able to use embeddable
fonts for the same elements. The question is more whether the
"standard" browser fonts are adequate, or whether a specially
selected font is justified for this particular web page.

The existing @font-face syntax is usable, although I can see
that it would be simpler in most cases to just include the
URL in the font list set by the font-family property, e.g.

  font-family: "TSCu_Comic", sans-serif;

  font-family: url(TSCu_Comic.ttf), "TSCu_Comic", sans-serif;

Where the first rule will apply in older browsers that don't
support the new syntax.

Some fonts have different files for bold and italic versions of the 
font, but you can always specify the file you need for a specific 
element as appropriate so this isn't a major problem. For headings 
in asian fonts, the file size for the complete font gets rather 
large. If there was an easy way to subset the font, then there would 
be benefits for using embedded fonts in place of images. This is 
another reason why being able to directly reference a font file 
makes sense.

As for the accessibility implications for image text replacement. 
Screen readers should be able to access the text even if the element 
is displayed with an image in place of the text. Using CSS to 
specify the image to replace the text is nice since it requires the 
text and keeps the markup clean. I can see a benefit from CSS 
allowing for fallback image URLs when the first image format isn't 
supported. Extending the background-image and content properties to 
support a comma separated list would be an interesting possibility.

One issue with embedded fonts applies to all new CSS features.
Until there is widespread support for convenient font embedding,
most designers will continue to use image replacements when they
want custom fonts. The web community needs to encourage browser 
developers to invest in the future, even though this won't have 
immediate benefits.



[1] http://www.microsoft.com/typography/web/embedding/weft3/

  Dave Raggett <dsr@w3.org>  W3C lead for multimodal interaction
  http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFETjLsb3AdEmxAsUsRAjJUAKDCw0jyZB6nOJYn3MlRkKx2qN5X6QCg7qPW
IOoP0gcEWLUf1Fo9Fcm6L7k=
=lnep
-----END PGP SIGNATURE-----
Received on Tuesday, 25 April 2006 14:32:34 GMT

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