In the latest issue of American Scientist I write about the awkward and ugly business of trying to present mathematical typography on the web. All the while I was writing the column, I had constantly in mind the uncomfortable knowledge that the column itself—with all of its examples of equations and arcane symbols—would have to be prepared for presentation in HTML. The conversion went more smoothly than I expected, thanks to the energy and expertise of Anna Lena Phillips. Nevertheless, I recommend reading the PDF version.
One issue that arises in this story goes beyond the particular problems of making mathematical notation intelligible. Why is it that a web page can’t include the fonts that are needed to display the text properly? It’s routine for web documents to incorporate images and audio and video and various kinds of code that affect the display of information—CSS, JavaScript, etc. When it comes to fonts, however, the web server is not empowered to supply what’s needed; instead, it has to play a silly guessing game with the client computer. “Do you have ‘Times New Roman’?” the server asks. “No, well how about ‘Times’? ‘Georgia’? Okay, give me anything with serifs, please.” It would be easier for both parties if the server could just package up a font and send it along—or so it seems to me.
This is not a new idea. Most of the recent discussion of embedable or linkable fonts focuses on legal impediments, which seem quite manageable to me (though of course I’m not a lawyer, nor am I an owner of typeface copyrights). Are there other reasons to back away from such a proposal? The bandwidth required seems moderate by present-day standards, and there are obvious schemes for avoiding waste by sending only glyphs that are actually needed in a document and not already present on the client computer. Publishers and advertisers would doubtless abuse the facility with garish attempts to attract attention, but we survived the <marquee> and <blink> tags back in the nineties, and an attack of circus-poster typefaces seems no more obnoxious. Am I missing something obvious?
No, just that the mills of the W3C grind slowly: see WebFonts, a CSS level 3 module.
There have been a number of technological approaches to making fonts available for embedding in web pages. The problems seem to be (1) said technologies are generally browser-specific; that is, they work in IE or Netscape but not other browsers; and (2), much more problematic, are severely restricted by the licensing of fonts.
There are fonts that are okay to look at, contain a sufficiency of glyphs to render most anything you might care to display, and have licenses that allow free distribution or use, but those aren’t the fonts that designers want to use (especially if they’ve committed to a particular set of typefaces for use in print publications). Most of the fonts favored by designers have licenses that impose severe restrictions on their use in any format other than print (where they cannot possibly be modified and reused unless someone redigitizes the type).
Very few font vendors allow embedding of fonts in PDF without restrictions. The most liberal typically allow subsetting, where only the glyphs used in a document are included in the document. But most impose an additional fee for embedding or bar embedding outright.
I suspect that these issues amount to security by obscurity, and are about as effective. It is possible to extract fonts from PDF documents and use them in other documents, but doing so is not trivial. Extracting usable subsetted fonts is even more difficult. But the possibility is enough to make most font vendors say no, even though the most likely source for pirated fonts is one designer copying fonts for a friend or sending them to a client by e-mail so they can edit a document.
To make these folks happy, any web-embedding system is not only going to have to include subsetting, but probably also encryption and some way of locking a particular downloaded font instance to a page or site (i.e., DRM), as any other approach will allow people to extract fonts and use them elsewhere. Failing that, we’re going to have to convince everyone that it’s okay to not have their website look just like their print publications, and if that movement had been more successful we’d have a lot less Flash on the web than we do today.
If the nub of the problem is worry over copyrights, then I want to know how type foundries got so much clout. Owners of copyrights on other kinds of content—words and pictures, music, movies—also fret about the misappropriation of their property, but they haven’t succeeded in getting the makers of web browsers to exclude text and images and other media from the online world.
As for PDFs, the ability to embed fonts in PDF documents has been one of the major reasons for the success of the format. It’s what puts the ‘portable’ in Portable Document Format. And I can’t help noting that PDF is the creation of a major font vendor. Adobe evidently considered it to be in their interest to let (some) fonts be embedded in PDF documents.
Is that true? I’m not being snide in asking that question. It’s just that I make a lot of PDFs, and I do it with software that’s supposed to observe all the legal niceties, refusing to embed fonts that don’t have the appropriate permission bits set. I can’t recall ever getting an error notice about naughty font transgressions. Maybe I just have a lowest-common-denominator taste in fonts. (In mathematics there’s no doubt that the most important faces are freely available—the Computer Modern faces from TeX and the STIX fonts.)
Anyway, whatever the legal status of the issue, embedded fonts are coming soon to a browser near you. Safari already does @font-face. Firefox 3.1 will do it too, and so will a future version of Opera.
Maybe Knuth took the wrong path, instead of turning mathematicians into typesetters, it might be easier to tun typesetters into mathematicians?
Downloadable fonts idea has been around since the birth of the web. Netscape 4 hacked it in ’98: http://bit.ly/n4NBO. Getting standards in place took a lot longer, and major browsers have just started implementing it:
https://developer.mozilla.org/en/CSS/@font-face
Fonts are a lot tougher to get right than images/sound/video web pages need.
Unicode has all the math symbols. Why can’t you use these for math presentation?
The Unicode standard offers code points for a very rich assortment of mathematical characters. It’s a big step in the right direction. But just because someone has installed “Unicode fonts” on a machine doesn’t mean there are glyphs available for all those code points. (At http://www.alanwood.net/unicode/index.html there’s a useful resource for checking what your own browser can and can’t display, given the fonts installed on your system.)
Another issue is that many of the glyphs that wind up being displayed when you rely on Unicode support are improperly sized or positioned or are just plain ugly—at least for those brought up with TeX sensibilities. Certainly it’s better to have some rendition of the character rather than none, but mathematics has enough of a pubic-relations problem without looking hideous too.
It seems to me that downloadable fonts would offer a more reliable and consistent solution. We’ll see.
@brian
Yes, it’s true — fonts contain an “embedding bit” that can be set to on or off. Most commericial applications (e.g., Adobe Acrobat) read and respect that bit, and won’t include fonts that say you can’t embed them. I’m not sure how well-respected the embedding bit is by FOSS tools.
Leaving the technical issues aside, fonts, like other software, are governed by software license agreements that may restrict their legal usage with or without technical limitations. Adobe happens to have quite liberal licensing for their fonts (no doubt in conjunction with their creation of PDF), so for most Adobe fonts you can embed them in PDF with no issues. But other type foundries licenses vary. (There are links to a bunch of licenses there; Emigre is one license with a separate embedding agreement (and fees); a couple of others from that list with restrictions are Elsner+Flake and LucasFonts.)
The license restrictions on embedding can range from “never, ever”, to “only if there’s no way someone can extract any of the font software” (which basically means never), to “only if the document can’t be edited”, to “sure, with an additional fee”, to “it’s okay”, and anything a lawyer can imagine and put into words.
I’m very happy with some of Adobe’s fonts and use them with TeX to generate documents for my own use, for my website, and for my employer’s website. But the embedding ban has stopped me from buying a number of fonts that I really like and would otherwise love to own — if I can’t typeset my resume and put it on my website, I’m just not going to buy the font.
We use Moodle to each distance ed students (www.oscail.ie).
Moodle has a nice feature that allows users to enter TEX fragments into discussion forums and render them as mathematical markup.
It gets around the font issue by doing the work on the sever and rendering the expression as an image.
So I go into a discussion forum and enter:
“What is the answer to $$ 4 ^2 $$.”
This come out the other end as image embedded right within the text so you would actually think it is done in font. Moreover I can click on the image and to reveal the TEX code which I can copy and paste to continue the conversation (that is expressions are copyable and modifiable).
- Eamon
Oh hey it just worked! I entered
two dollar signs then 4^2 then two dollar signs
Brian - thanks for very interesting posts and particularly for pointing me in the direction of jsmath, which looks like a very interesting option for math blogging.
If I understand correctly, once you install it along with the tex2math plugin, both you (the author) and users can embed math within the standard $\LaTeX$ delimiters… Is that the case? I hope you don’t mind that I’m hijacking this thread, and this post - in fact, this very paragraph - to quickly check that ;-)
$$
e^{2\pi/5} (\sqrt{\varphi \sqrt{5}} - \varphi) =
\frac{1}{1+\frac{e^{-2\pi}}{1+\frac{e^{-4\pi}}{1+\ldots}}}
$$
(Note: This doesn’t seem to work in preview, which I guess makes sense, but it does make it harder for users to check their code.)
@Alon
By default, you can’t use the $ delimiters unless you tweak a setting in the main script (otherwise you’d have people complaining that their money references caused their pages to break). Instead, jsMath uses \( \) for inline math and the standard LaTeX \[ \] for display math.
Thank you for the interesting article in the American Scientist. There is a mathematical typo in it, however. In the image on page 3 (on the web version) you have a sign error in Euler’s identity; (let’s see if this Latex works) $$e^{i\pi}-1=0$$ should be $$e^{i\pi}+1=0.$$
@Dave Richeson: Thanks for posting that. As another ongoing thread on this site makes clear, I do have trouble getting numbers right, and apparently the difficulty extends all the way down to +1 and –1.
@Alon: As you have surely inferred, I have enabled the use of $$ … $$ as a marker for display math, since I think it unlikely anyone will need that particular sequence of symbols for other purposes. But I’ve disabled $ … $ for inline math, so that we don’t have to escape every dollar sign. As Claire pointed out — or tried to point out — \( … \) and \[ ... \] also work.
But, as Claire’s comment illustrates, it’s a bit of a bother to talk about these markers in a venue where jsMath is eagerly trying to interpret them. I thought that a simple backslash escape would do the trick, but apparently not. I fixed Claire’s post and this one by adding a class=”tex2math_ignore” declaration, which is not exactly obvious.
I remain undecided about the whole jsMath experiment, and I may yet switch to a server-side solution. As you point out, jsMath doesn’t work in the comment preview window, but then I’m not ecstatic about the preview function anyway. More serious, it doesn’t work in RSS readers, and I don’t think it ever will.
@Brian, @Claire - thanks to both of you.
Interesting point about RSS, Brian. I was leaning towards just using WordPress for my blog, which includes a server-side implementation of LaTeX as I’m sure you know, but I’m intrigued by certain aspects of jsMath. Thanks very much for sharing your perspective.
I could think of only one reason why fonts are not rendered embeddable: i.e. having thousands of fonts out inhibits any chance of standardizing the output we get across different browsers and platforms.
@shinn:
Perhaps I misunderstand your point, but I think the situation is just the opposite. Under the present regime, a given web page can be displayed in many different fonts, depending on which ones happen to be installed on each client machine. Fonts embedded within a page would display the same everywhere.