Anne van Kesteren

Font MIME Types

roc reports on the Web Fonts battle of which the short version is whether the non-IE browsers should support a DRM format for fonts. (And maybe also whether they can support TrueType and OpenType out of the box.) I don’t really think we should support a DRM format for fonts. It seems like it would set a bad precedent on the Web, might make vendors liable if they don’t enforce things right, and complicates matters for authors.

The W3C has created a draft charter for an EOT Working Group; EOT (Embedded OpenType) being the DRM format Microsoft is advocating. I have no idea how EOT is leading the Web to its full potential, but we’ll see what comes of it.

Aside from the format issue it might be worth considering to introduce a MIME type for fonts. (If this is too late for implementations at this point it might be too late.) The upside is that arbitrary files (say, a text/html file) will not be interpreted as fonts. The downside is that it makes things slightly harder for authors as they have to make sure they label it correctly. (On the Web images (except SVG) and JavaScript are not checked as to whether the resource has the correct MIME type. For images the browser sniffs the image signature and something loaded from a script element is simply executed (not so good, indeed).)

Given that support @font-face will be shipping soonish in Opera, Safari, and Firefox this would need to be decided soon. Probably before the relevant MIME type is standardized through the IETF. Another complication is that OpenType and TrueType can carry either otf and ttf as extension and the operating system deals with it fine. Having a single MIME type for both could probably work though, just like XHTML and SVG can both use text/xml.

So, should we try to go for something like font/opentype? Is there enough time?

Comments

  1. So Safari shipped with this long ago and I forgot. Oops. Maybe Mozilla and Opera can make enough of an impact for this to change?

    Posted by Anne van Kesteren at

  2. Is there a reason to not implement this at any stage? I think it's quite obvious that fonts need their own MIME type. And right now we are in a position where only one browser has this implemented and getting this through IANA shouldn't take that long, should it?

    Posted by Asbjørn Ulsberg at

  3. @Asbjørn: The rule on the web seems to be "once we ship it, it can't be changed"...

    When authors start relying on "broken" behavior transition costs rise. If you are the market leader. Or something like that.

    Posted by Grey at

  4. Grey, it’s not quite as black and white like that, but for certain things that is certainly true. (Though mostly this only goes if the top four browser vendors do the same thing.)

    Posted by Anne van Kesteren at

  5. We absolutely must not support any form of DRM in fonts, or any other format for that matter. The whole concept of DRM is totally incompatible with Free Software, so that means Gecko and WebKit couldn't support it.

    Besides, there is no form of DRM that has been or will ever be sucessful, since the whole concept is fundamentally flawed. Given enough motivation to do so, hackers will find a way around whatever DRM scheme is implemented, and so it only ends up being a waste of money for content producers, and a hinderence to legitimate consumers.

    Posted by Lachlan Hunt at

  6. I've added -- experimentally -- content types to the font files on www.princexml.com. For example, try this:

    wget -S http://www.princexml.com/fonts/gentium/gentium/GenAI102.TTF
    

    This is my .htaccess file:

    AddType font/ttf ttf
    AddType font/ttf TTF
    AddType font/otf otf
    AddType font/otf OTF
    

    I prefer the shorter names. EOT and SVG will also fit into this scheme. I should also add that I'm an EOT-sceptic.

    Posted by Håkon Wium Lie at

  7. Now the archives of ietf-types are back up I can provide a pointer to my e-mail: OpenType MIME Type.

    Posted by Anne van Kesteren at

  8. @Asbjørn: The rule on the web seems to be "once we ship it, it can't be changed"...

    While I generally agree with you, I think fonts are still such a rare sight on the web that we can start implementing MIME types for them now without causing too much havoc and breakage.

    I've added -- experimentally -- content types to the font files on www.princexml.com. [...] This is my .htaccess file:

    AddType font/ttf ttf
    AddType font/ttf TTF
    AddType font/otf otf
    AddType font/otf OTF
    

    I prefer the shorter names. EOT and SVG will also fit into this scheme. I should also add that I'm an EOT-sceptic.

    I think this looks excellent. What would be required to get a new MIME type registered? An IETF RFC and nothing else? If so, who writes it and when? :-)

    Posted by Asbjørn Ulsberg at

  9. Hmm, I've published a new font for the web at http://abattis.org/cantarell/ and I'm having problems with the @font-face not rendering for the regular in IE (where it uses the bold throughout) and in safari 3 on mac (where it uses the bold in the titles and strong tags, but drops the regular) - but it works fine in Ubuntu FF3.5, Opera 10 Beta and Safari 4 on windows (thanks to browsershots.org :-)

    I wonder if this is a MIME problem.... Sadly debugging font linking seems like an imposssible task to me; no feedback at all on why things work or not...

    Posted by Dave at

  10. Okay, problem solved - it was indeed a MIME problem, fixed by simply adding a file named ".htaccess" to the directory that the fonts are in with a single line inside:

    AddType application/octet-stream .ttf .eot

    Posted by Dave at