Tuesday, July 22nd, 2008

The Fight for Fantastic Fonts (or, Let’s Give Tahoma a Rest)

Category: Browsers, Design

What’s the greater of these evils: contorting site designs around the standard Web-safe fonts, using images to render type, or relying on sIFR to render type with Flash?

Who knows, but man, it sure would be nice if we could reliably use any font we wanted in our web work. And, as it turns out, IE4+ and Safari 3.1 offer mechanisms for doing just that.

Safari’s shiny new mechanism is based on the CSS3 @font-face “at-rule”, exemplified thusly in the spec:

  1. @font-face {
  2.         font-family: "Robson Celtic";
  3.         src: url("http://site/fonts/rob-celt")
  4.       }
  5.       H1 { font-family: "Robson Celtic", serif }

The linked font can be a regular old TrueType font. Compare this to IE6/7 which also support the @font-face at-rule but only support special “Embedded OpenType” fonts.

At first blush, you and I might think, “Yay for Safari! And, thanks IE for yet another screw.” But that was before we considered the DRM issues. You see, there’s an established technology for enforcing the use of fonts in embedded applications, and CSS’s @font-face bypasses it by directly linking to TrueType fonts. At least one major font foundry is mighty uncomfortable with the thought of more browsers following Safari’s lead.

Hence fontembedding.com, a newly-launched site promoting the virtues of the long-misunderstood and under-loved Embedded OpenType (EOT) format and the evils of linking to TrueType on the Web, complete with a call to action to other browsers to support EOT once the recent W3C EOT submission is ratified (i.e., maybe we can expect to use them cross-browser in 2014). EOT, you see, embeds the URL of the website that licensed the font for embedded use so that User-Agents can enforce font licensing restrictions.


I wish them luck with EOT; in the meantime I suspect Firefox will implement @font-face and enough high-quality freely embeddable TrueType fonts will emerge to ensure that EOT remains as irrelevant as it ever was.

But then, I’ve been wrong before.

Still, fun to realize that as soon as Firefox implements @font-face, thanks to TrueType-EOT converters, we can finally use fonts on the web. Myspace will never be the same.

Posted by Ben Galbraith at 8:00 am

3.8 rating from 31 votes


Comments feed TrackBack URI

Anyone thought about the phishing possibilities that arise by these features? Imagine a ROT13 font…

Comment by muhqu — July 22, 2008

will anyone ever (be able to) enforce font licensing on the internet?

sort of like the CompuServe GIF copyright… ?

Comment by davethieben — July 22, 2008

Though fairly trivial, perhaps @font-face (non-EOT) fonts could be placed under a path protected by a simple “same-domain” policy (eg., HTTP referrer checking via .htaccess.) EOT allows you to specify a list of domains which the font can be used on (http://ajaxian.com and http://www.ajaxian.com/ for example), but I suspect this format could be easily editable.
Microsoft’s WEFT (Windows Embedded Font Tool) allows you to create .EOTs from fonts on your system, and it tries to abide by the “embeddable” bit set on fonts on your system. That being if a font is not marked as being embeddable, you should not be allowed to create an .EOT from it. I recall finding a font editing tool years ago that would also let you edit the “embeddable” bit on the source font. Devil’s advocate here, perhaps. ;)
Licensing/IP is going to be problematic when this catches on. Casual font “sharing” may happen already in the design world, but the embedded web stuff as shown may also make the source files a little too-freely-available to anyone who pokes around.

Comment by Schill — July 22, 2008

I just completed a worldwide site that needed fonts in many different languages to support Japanese, Korean, Hebrew, Turkish, etc. I solved this by simply generating the images on the server using Java2D. The servlet has a cache so images only need to be generated once. With this strategy you can use whatever font you want. You could even read a CSS file from Java to determine how to render the text.

Comment by mchammer — July 22, 2008

This is one for Google to fund as part of Android:

1) Query Google’s cache of the web, tabulating fonts used in .doc documents.
2) Pay someone to create high quality outlines+kerning of the top 10 fonts.
3) Release them under a FOSS license.

Finally, Google could provide a hosted service which generates minimal TrueType font files for just glyphs (pt sizes) required on a page. This could be referenced by third party webpages in their CSS. This hosted service would generate these minimal TTF’s on the fly and use their caching/CDN to have minimal load on their systems.

Comment by RichB — July 22, 2008

@mchammer, now that you are finished I will make the recommendation to use SVG and Batik instead of Java2D directly. SVG does a great job with CSS, furthermore you can build an XML pipeline to convert XML -> SVG -> PNG, via XSLT and Batik. I do exactly that using Servlet Filters.

Comment by JonathanLeech — July 22, 2008

Wait so to be clear, this post is a defense of the DRM mechanism MS built into IE to prevent you from publishing with a font you payed for? Just, as I said, to be clear.

Comment by eyelidlessness — July 22, 2008

@eyelidlessness: The piece is neutral; it’s pointing out the recent announcement by Ascender and MSFT re: EOT and the W3C submission and contrasting against the direction of WebKit. I’m interested in hearing from font designers who make their living off licensing type faces; they have the right to define the terms by which their product is used. I’m somewhat less interested in the opinions of large companies who hold the rights to large libraries of typefaces.

Comment by Ben Galbraith — July 23, 2008

I don’t understand why there is so much DRM concern with fonts. After all, nearly everything you can use in a page can be copyrighted: images, text, overall design, video, sound. And any font can be used if you really want to anyway. So, why this nonsense? I think it should be corrected so hopefully the font-face rule will be implemented so that any font can be used, no DRM involved.

Comment by jordi — July 23, 2008

I’m too lazy to find the reference, but the main objection the Firefox guys have against implementing font embedding any time soon is because of the security bee’s nest it opens up.
Font drawing libraries haven’t been designed with security in mind, which means that until they’ve been thoroughly tested for that particular use case, they’re probably vulnerable to a wide range of buffer overflows and what not, esp. considering that they probably have been optimised for speed, and are likely to have assumed correct input.
Even GIF decoders have suffered remote code execution holes, and you can’t really get much simpler than that.

Comment by nixar — July 23, 2008

fonts—the technological reifications of writing—are at the very core of the web (and much more). there are gazillions of DRM-free font faces in the world.

it is a shame that just because some font vendors (who admittedly deliver great products and have done great research to build and develop font technologies—something that plainly didn’t exist only a few score years before) are anxiously guarding their trade secrets we are so hampered on the web to use fonts.

and despite more than a single effort by major players to promote formats that manage to be secure and copyright-abiding, in 2008 we are still tied to a handful of standard fonts.

among other things, this means people who want to display content in anything other than the major languages have to ask their readers to manually download a font and install it on their computers (something that users in corporate environments often are not even allowed to do).

so the lack of a common technology to display custom fonts means all but a few scripts can only be displayed as images on the web—which, at its heart, is a text based format! this is a culturally and technologically unacceptable situation.

we have unicode but are unable to display major parts of it on a majority of web browsers? say what?

one possible avenue to solving part of this problem might be to reimplement font rendering inside the browser, maybe even using pixel based fonts. the browser would make a request to the server for a particular font in a particular size and get pixel-based information—little gifs if you want—back, together with kerning information and such.

those images can then be arranged by the browser to produce the text desired (of course, a system service could be installed that can then be used by several display clients—clearly a favorable arrangement). when a user rescales the display, another request for other sizes would be issued. yes, malicious users can steal a font’s pixels that way, and even reverse-engineer an approximate vector shape by requesting a pixel font at a high resolution. but that would not be the original—and the same problem exists with paperware. after all, the original author or editor bought a license that covered publication, and a malicious user can then scan a book and reconstruct a typeface in lead from that if they wish. the web doesn’t change that aspect.

if we want the web to advance, we clearly must find a way to pass around script shapes (and rules for script element arrangement) the way that textual content (using unicode) and graphical content (using jpgs/gifs/pngs) is already passed around today.

i imagine a protoype could be built using nothing more than (1) the famous css sprite technique (big image with alphabet, small div that displays part of it), (3) javascript to build divs that represent typographical words (so line breaking can work) (4) ordinary css to describe and position such shapes. such a prototype would be sluggish as hell for longer streches of texts, but could serve to demonstrate the feasability of the concept (or prove its inaptness). (5) give it a cool buzzword. (6) profit!

Comment by loveencounterflow — July 23, 2008


Comment by aheckmann — July 23, 2008

@JonathanLeech – The problem I’ve had with SVG and Batik is that in the case of a horizontal menu, I want the size of the graphic to vary depending on the size of the text inside. German text will of course be longer than English or Spanish. When I’ve done it with Batik, I have to force an arbitrarily large size to make sure that all text fits. With Java I can look at the final glyph and crop accordingly.

Comment by mchammer — July 23, 2008

ok one more word in addition to my lengthy post above: some of the comments to the article referenced by aheckmann are worth a read. the shorter ones are the better ones. take your time to take a look at that billhillsite dot com, too—jeez. that’s one of microsoft’s typo big-wigs, and his web site looks like pur CRAP.

one of hills’ commentors says something to the effect that “web font embedding is quite nice, but doesn’t add any functionality”. guys, whenever you’re challenged with a statement like this, keep in mind that

(1) form is function, function is form (a crappy font cannot transport meaning, since you can’t read it).

(2) beauty of a presentation *is* the presentation as soon as you go beyond mere data transmission.

(3) display in custom fonts becomes an absolute necessity (not ‘aesthetic icing’) when you can not assume the audience to have compatible fonts installed on their systems. true for many languages, in many countries.

(4) can please anybody who supports drm just leave the room rather sooner than later? there is enough copyfree fonts around; if drm people cannot bear that, they’re free to get themselves sidelined. thanks ;-)

Comment by loveencounterflow — July 23, 2008

@mchammer –
Font font = new Font(“Helvetica”, Font.BOLD, 10);
FontRenderContext frc = new FontRenderContext(null, false, true);
Rectangle2D bounds2 = font.getStringBounds(label, frc);
bounds2.getWidth() // The width the text will be.

This admittedly doesn’t fit in too well with the whole XML pipeline concept I outlined, or the fact that CSS can set the font properties.

Comment by JonathanLeech — July 23, 2008

@Ben Galbraith:
So we’re supposed to interpret “the virtues of the long-misunderstood and under-loved Embedded OpenType” and “I wish them luck with EOT” as neutral?

Comment by eyelidlessness — July 23, 2008

“they have the right to define the terms by which their product is used”
This is a little disingenuous, and not at all a safe assumption. First, are you talking about rights (the things granted to us by our creator [or nature], a wishy-washy area of things we ultimately need to define in social convention in order to approach protection) or rights (the things codified into laws)? If we’re talking about the former, then there’s no clear answer either way. If we’re talking about the latter, while there’s also no clear answer either way, the legality of “fair use” and enforcement of EULAs and other similar non-contracts-treated-as-contracts is hotly debated, with legal precedents pointing very strongly in both directions.
That is to say, neither the morality nor the legality of restricting the use of something after you buy it are clear. You’re taking a position, it is not neutral. And that’s fine, but at least be honest about it.
And, I happen to disagree. Especially considering the context. The context basically requires you to either decide that a person can embed a font into a web page, or that a person cannot use the font for publishing (its obvious purpose). To put it another way, if you are creating a font and expect people to buy it but not use it, you’re a crook at best.
“I’m interested in hearing from font designers who make their living off licensing type faces […] I’m somewhat less interested in the opinions of large companies who hold the rights to large libraries of typefaces”
Unfortunately, while the two are have distinctly contradictory power and weight, they are treated equally by the law. Moreover, those with smaller economical power generally benefit from fewer restrictions whereas those with greater power benefit from more restrictions. If you want to empower small time font designers, the way to do it is not by empowering big companies with basically anti-end-user DRM.

Comment by eyelidlessness — July 23, 2008

I get heated and type so quickly, and make stupid errors.
“are have distinctly contradictory power” should be “have distinctly disparate power”; “economical” should be “economic”.

Comment by eyelidlessness — July 23, 2008

Leave a comment

You must be logged in to post a comment.