Fonts on the Web
I’ll get that second half of the font protection discussion up soon. But it’s been forever since I posted – the Macromedia merger has been a huge time sink, and my other work just hasn’t gone away, so blog posting was the thing I could most afford to put off.
Anyway, an interesting discussion was generated by this rather goofy manifesto, both on the original site, and here on Typophile. Basically, somebody wants to be able to use more fonts in HTML, and has some confusion about how best to accomplish that – he thinks the type foundries are to blame for the current lack of options, and suggests that fonts need to be liberated from their servitude to their type foundry masters.
My response, which is somewhere in both those lengthy threads, I reproduce again here:
Norbert has it exactly right. The problem is nothing to do with the font companies or font designers. And they certainly aren’t greedy – if they were, they’d be in another line of business.
The overwhelming majority of type vendors and designers already set their fonts for “preview and print” embedding, or some more liberal setting. They’ve already done their part.
The problem is that there is no universally accepted solution for font embedding on the web. I think Adrian sort of gets that, but he seems to think that it’s up to the font folks to solve. But really this is a problem for the web folks to solve – perhaps with input from the font people.
Any of the previous solutions that relied on distributing fonts for end users to install up front has been fundamentally flawed. insofar as it keeps designers using a handful of fonts that are universal, and relies on something largely outside of their control – that the user already has the font installed. Even if the fonts are freely available, the web is too much of an instant-gratification medium for web designers to be able to rely on people installing specific fonts just to view a site.
The W3C is considering a new mechanism that would allow a reference to a font in a specified format on the web site, perhaps in a Zip file. That’s an improvement, because it gets the font automatically loaded – but you’d still be limited to free fonts, which isn’t very exciting. And convincing the rights-holders that they should give their work away isn’t going to work here any more than it did in the music industry.
Still, it’s a big problem. You need to convince the folks who own the web browsers and the web authoring applications that there’s a big market for a solution. The font foundries already know this and most of them are as eager for a good solution as you are.
14 Responses
Comments are closed.
I think this is a good method to embed fonts in HTML. http://www.mikeindustries.com/sifr/Bob
Bob,Yes, SIFR is probably the best option available today (more cross-platform than WEFT). However, it still has some limitations, and more importantly it isn’t directly supported by any of the common web authoring tools, is it?This is what I mean by pursuading the key players – need to convince the web authoring tools vendors (of which Adobe is now the main one) that this stuff is important. Then, whether it’s SIFR or some other technology, it needs to be in the commonly used authoring tools as well as supported by the browsers.Regards,T
I have been following this “manifesto” as well. The author claims that you don’t need a font to see a film, or to read the titles on a TV show.However, you do need a font to produce the titles for a TV show or film. I think that is all the font companies are asking.The problem is not the font companies desire that browser owners buy their fonts, but that the w3 group have not developed any way for fonts to be shared in a manner that protects the font maker.W3 has always ignored design esthetics. They have been dragged into developing CSS by the addition of tags like font and others that tried to compensate for the lack of typographic support.I wonder if they care about the font problem at all. Probably they are more concerned about getting math formulae to display than fine typography.I agree, Thomas, that some system needs to be made a standard. I’m not familiar with SIFR, but if would work then it should be used and promoted.But I find the w3 group the villans of the piece, not Adobe and other font manufacturers.
SIFR is a nice workaround for font embedding on web pages, but it is still a workaround and it lives like an alien on the web page. You can not use the browsers “Find on page” command to find the text; the flashed text is not selected if you chose Select All on the page, and the text is not resized if the HTML text on the page is resized in the browser. But still, it is better than setting the text as an image.
Yes, those are the kinds of significant limitations I was thinking of for SIFR. But as you say, it’s probably the best option available right now.T
Dear Thomas,I could do nothing but agree with you, it’s a web (W3C, browser makers) problem. But I disagree that free fonts isn’t very exciting. There are lots of interesting fonts out there, most of them are not suitable for type, only for titles, but, unless our screen resolution get really better, I believe most people is happy with what you’ve got with most OSs for text. I’d be very happy if I can have my titles displayed with a custom, free font. I belive that titles are the main problem here. And I don’t want more hacks like SIFR.Regards,Demian
Thomas, do your remember that during TypeTech Helsinki, there was a presentation about typography on the web? It was some kind of server-side embedding. Unfortunately I don’t remember who it was, or what technology was it.
>1) You can not use the browsers “Find on page” command to find the text;With sIFR (scalable Inman Flash Replacement) you have accessible html-text, most “technically” important. And if javascript is activated and the user has Flashplayer >=6 installed, he can look at the flashfile with embedded text. Otherwise it degrades to regulary css-formated html-text, displaying one of the available fonts on the userssystem -font-family: cambria, georgia, serif;That`s good for layoutpurposes AND accessibility. Ok, it`s not perfect, but one step forward.2) the flashed text is not selected if you chose Select All on the page, and the text is not resized if the HTML text on the page is resized in the browser.You can build up the website with a (css)concept called “elastic layout”, where the user can zoom everything on a website consistently. It behaves the same way as the zoom-function in opera. This concept has another advantage – you ship around the “missing hyphenation issue” with that – pagelayout stays the same. Something negative about it: With this you can’t control line-spacing, that would fit the changing fontsizes, but it is also a step forward.Regards ThomasP.S.Excuse my poor english
Gabriel:I believe you’re thinking of GlyphGate, which is a pretty cool technology. If it were a publicly available spec (or better, open source) instead of completely proprietary, that would be great.Cheers,T
Embedding fonts in images is not an option as it violates accessibility. SIFR is a hack. We need a real solution and I agree it isn’t (solely) the foundries’ responsibility.As a web designer, I should be able to to create a “fonts” directory at the root of my website where i toss in (DRM-ed?) display-only versions of fonts that I, as a web designer, have purchased.This would require support from:the W3C — for a standard inclusion via CSSmajor web servers (Apache, IIS, etc) — to serve display-only fontsmajor web browsers (IE, Firefox, etc) — to display display-only fontsfont-foundries/designers — to enable display-only fontsJust imagine: if all those web designers out there creating pages in the same old Arial/ Verdana font specs suddenly had the ability to purchase (for a nominal display-only fee) beautiful fonts, then the web designers who truly cared for such matters would.
What would it take to make a font display-only?
Simple. The font container would be created at runtime, locked with a one-session-only license key string that would be created server-side on the font-request. This once-only key would in turn be spawned from the developer’s permanent license key, but this permanent key would never travel, thus making it impossible to retain by any client-side attempts. The once-only key would be echoed into (most logically?) the css file. The css file calls for the typeface in a standard fasion (@font-face or similar) with the echoed once-only key as an extra css attribute (how about font-key:[#key]?) This way you are not dependent on session or cookie variables being constantly reachable. Yes, we do need some sort of session going, but worst-case scenario is the spawning of a new key and container. The point being that the key and container dies after one use.(Sorry if my logic is somewhat flawed, I’m sure you catch the drift anyways.)Getting a scheme such as this of the ground server-side-wise would be sorted in a jiffy. The php-gang would go for it at once. I’m certain. Once they do, so will everyone else.So who’s gonna pick up the ball? The w3c? m$? moz? No need really. The CSS standard as such already allows for the tagging I’m suggesting. The font-foundries can probably package their fonts in any old container they see fit. We need an encrypting guy who would look this over and then start licensing out the required mechanism to the foundries. We can then add this functionality to our style sheets. What’s missing? The browsers. Most of them do have some functionality that can cope with the above scenario. We would probably have to start with javascripting and maybe active-x’ing but I have a feeling that, like designMode() (rich-text-editing), it will catch on fairly quickly.What I gather from this is that, in fact, it’s more up to the foundries than to the other parties involved. And what foundry has most to gain?Yeah, that’s right. ;)So go for it!Ben
I don’t quite understand why font foundries would have an issue. Afterall fonts can be embedded in PDFs and Flash (which is why sIFR can do what it does) which implies that the issue of font rights management is already sorted.What is required is a similar mechanism of getting the fonts onto people’s computers (or ‘within’ their browsers) and for the browsers to render said fonts. Clearly this isn’t a trivial thing to accomplish as it needs to be as ubiquitous as, say Flash, in order to have any impact. So how about building something akin to sIFR within Flash player?
Quoting Ryan Price> This would require support from:[some elements of the list here omitted]> font-foundries/designers — to enable display-only fontsI enjoy designing and making my own fonts and have published some of them on the web.http://www.users.globalnet.co.uk/~ngo/fonts.htmPlease know that I am happy for those fonts to be used for experiments to make such a technology work, and indeed for them to be used for practical everyday use if the technology can be made to work.Supposing that such a system were made to work, what would I need to do to, say, my Chronicle Text and 10000 fonts to enable display-only fonts?For example, would this mean altering a flag within the font using the fontmaking program or would this mean running some piece of software yet to be devised using my font CHRONTXT.TTF as input data for that piece of software so as to produce a new file, say, CHRONTXT.TTW which includes all of the font information and also the intellectual property rights protection additions so that the font could be used in a display-only manner on the web?William Overington7 September 2006 (as it is morning here in England)[apologies from Thomas – somehow lost this amid the usual comment-spam]