Interview: Opening shots in
the Second Font War
SURPRISE ANNOUNCEMENT from Berlow: An on-screen font solution that may save our eyes from being ruined by reading too many web sites.
David Berlow is the founder of the Font Bureau, of which I am a partner—but David has done all the work building a community of type designers and a great library. He has also enjoyed the technological toboggan ride, starting with his phototype days at Linotype, his early digital work at Bitstream, and then Postscript fonts for the Mac, Fontographer, Robofog, Truetype GX (the less about which, the better).
We’re coming to another turning-point in the technology of type, when online designers may get a richer typographical palette to work with. (Remember the desktop publishing era "font wars" of the late ’80s?)
No one has a better grasp of the changes in store than David, and so I asked if he would answer a few questions, starting with Microsoft’s ClearType, which is the format of the system fonts in their new operation system, Vista.
* * *
RB: We’re hearing a lot about ClearType all of a sudden. Is it the answer to screen readability, or just another font outline format?
DB: MS’s ClearType is just two things, an anti-aliasing filter, and a collection of fonts made specifically for ClearType filtering.
But let me back up for a second. This is the third shoe to drop in the desktop anti-aliasing tripedal “sack race.” Adobe released ATM, (Adobe Type Manager), which included a grey scale font filter, in 1991, introducing the Macintosh audience to the visual qualities of anti-aliased fonts. In 1999, Apple Computer released OS X, which included Quartz, Apple’s own anti-aliased font filter. CT is the third filter producing anti-aliased desktop type and it was introduced in a preliminary form with the release of Windows XP. The ClearType font collection, one that takes some good advantage of the new filtering, was begun in 2002 or so, and are now becoming available, accompanied by a large amount of push. Apple did not make any special fonts for Quartz, and Adobe did not make any special fonts for ATM.
RB: But what about “sub-pixel rendering”? To hear all the talk, ClearType fonts make text on a flat screen look like laser printing. I’ve gotten the impression from Microsoft that this is the best thing that has happened to reading since the invention of the electric light bulb.
DB: ClearType is in fact the best thing to happen in the long time, for Windows typography. Adobe was sub-pixel rendering over a decade ago and Apple since ‘99. There are two differences since then (at least). One is that since those older sub-pixel rendering solutions were developed, screen resolution has finally improved to the point where laser printer quality is possible. And the second thing that’s changed is that web has brought billions of users face-to-face with the world of scripts on the screen. So, relative to where MS was, this is a vast improvement. Unfortunately, MS has selected a path that eliminates the possibility of achieving the highest possible quality for all those scripts. Heck, they have not been able to either perfect or even document their Latin development.
RB: Adobe and Apple already had screen fonts that look as sharp as ClearType?
DB: False. They do have sub-pixel rendering. They do not have adjustments of the outline to better fit the grid, nor do they have integer metrics, (the widths of characters falling on full pixels), which insure the repetition of each character.
RB: And what happened to CoolType?
DB: It is buried in side of Adobe Products, allowing them to span the non-standard behaviors of the two platforms (MS bad scaling, monitor manufacturers who lied), with consistent type, even compatible type. AKA Kluge Central.
RB: Then, why are PDFs so blurry?
DB: PDFs use sub-pixel rendering, but they do not use adjustments of the outline (hint, instructions or variations), to better fit the grid, nor do they have integer metrics, which insure the repetition of each character, so if you set 12 l.c. eyes, they are not the same across the page. There are up to 8 versions of each letter in PDF and Quartz, 3 or so in CT,
1 in Mine.
0.
Ignition.
RB: Wait, you have your own solution?
DB: I have my own contentions. And the main one is that using hints to deform the outline for either Quartz, or ClearType, is most certainly futile, maybe also feudal. And I also contend that ad hoc positioning of the letters on sub-pixel boundaries, introducing variation to the letterforms and their surrounding spaces, is less conducive to reading than laying down regular letterforms and spaces. I do not contend that the other methods should be discontinued, only that a more precise option should be available if that is possible.
What I’m preparing to release is an alternative of the problem of screen fonts for email and the web. This alternative assumes that the composer and user have access to the same fonts, not a simple trick in itself, and that both have the options of size, (currently 8 to 16 pixels) and weight (like the grades in our print fonts), more firmly in their grasp than they do in current browser and e-mail applications. Now these standard Internet clients offer the simple choice of regular and bold, with a hand-full of widely separated sizes, only two of which are of any use. Instead, I propose that a wide range of options should be at the user’s command.
My solution is based on the type designer providing multiple drawings, like multiple masters, but instead of defining weight or width in the multiple styles, the type designer provides contours to match the grid size of particular sizes, like 8, 12 and 16. So the type designer is positioning the outline precisely on the low-resolution grid, a fit that is much closer than hinting can ever achieve. The designer controls the exact color of each feature of each character in the a way that produces an optimized result for any font and any script at any size, without having to write software, (hints).
RB: Is this like Matthew Carter’s design for TrueType Georgia and Verdana, but with a special outline for key sizes?
DB: Georgia and Verdana, Chicago and Geneva too. All were designed to meet the low resolution grid precisely at one size, and then bashed around by others using hints until they worked okay on the other sizes when aliased, i.e. B&W render’d. But in B&W, the solutions are limited and so hinting works. Nobody ever asked Matthew, e.g. to do it over and over again, until they could see a range of Verdana perfecto.
RB: Are you talking about a whole new font format, or are the sized outlines bolted onto, say, OpenType?
Not sure how the best way to represent this in a format is, though I think GX Variations was the closest. And, if you had control, like MS, e.g., over the OS, you could certainly do it with a small number of the existing hints in TT. The other interesting option, is to serve the right ppm font by network, since internet publishing to all three platforms only requires three sizes at most for the main “text face,” you are free of the operating systems completely, assuming the closeness of CT and Q is where I think it is, and if not, it might not matter what differences there are in those two renderers because the directness of the delivery and density of the options would make it simple to supply the user with whatever differences are required by the OS per the user’s request.
RB: And what about smoothing? Does your idea eliminate hints and smoothing?
DB: Hints move the outline to a spot where smoothness, a subjective concept, is best. I contend that there is no more a single solution to smoothness of screen fonts than there is a consensus for the best layout of buttons in an interface design. I want the choice to be available to both user and publisher.
RB: Are we just getting back to bitmaps?
DB: It might seem that way from the one-size-fits-all point of view, to a one-size-addresses-one-size product, but bitmaps are much more limited in what they can do, either to address the different grey-scale schemes going leadins to the most critical difference being with OT, I’m presenting an outline just like any other font that works anywhere with minimal enabling software dedicated to the imaging, and maximum dedication to delivery of a high quality screen font. In addition, if you want to use one of my fonts at another size, it scales smoothly, unlike a bitmap. And also, the skill set of the type designing community has upgraded to outlines wholesale, so they, and anyone else who wants can grid on up to the bar, draw away, and improve things right off the bat if they feel like it, as opposed to lego-like bitmap design, or the elegant but ultimately limited TrueType hinting language, which at its best becomes a complex set of measures and rules, far from the direct manipulation of outline by designer.
RB: People at Microsoft say ClearType is optimized for edge recognition, and Adobe goes for smoothing. Is a more defined edge better for small sizes, or do we want controlled anti-aliasing?
DB: Everything ends up as bitmaps for screens, as you know, and the higher the resolution, the better-off the reader is. Whether this higher resolution comes from a combination of huge screen, distant user and relatively large type, or it comes from 144-200 dpi devices in the palm of our hand 6" from face, naturally high resolution like this moves the troubled range of text type from the 9-17 pixels per em, to the 18-34 pixels per em and makes things much better. The other question, what’s best! down where we are? I have partly answered, that is to say, there is no best. Some people are reading far away, some close, some high-res, some low. . . . Some use black type on yellow background, others yellow on black. . . . Some people like to read bitmaps, B&W, some like minor fuzz, some like directionalized fuzz, others can’t take it until it’s all fuzzed. This changes not only per user, but also in use, i.e. the user may change over time, or need different rendering treatments on their many different devices, or just want something different.
RB: So when is your format going to be ready, and what do we do in the meantime?
DB: It is not a format, but rather each size is a distinct and fully functioning TT font that can be used today! So, it is a combination of the oldest form of type, a single master for a single size, and the new form, a TT font. Additional development would be in the interest of whatever data compression could be accomplished without loss of quality, and of course more fonts.
I use the alphatype type now for e-mail, something I was forced to do as, while creating these new fonts, I became unable to use the old fonts I had relied upon for eight years. On the web, these fonts face the same barriers as all other fonts not bundled across-platforms, that being that the network/browser OS is not yet sophisticated enough to present any font to any user on any platform.
RB: Thank you, David. Let's start a new round of questions and answers on font embedding soon.
Your Thoughts (5 comments)
2007-02-03 by T4S
A designer's perspective?
This is a refreshingly simple concept, so naturally one has to ask, why hasn't anyone proposed this as a solution for web typography? Is it just too expensive to get a type designer to draw separate outlines for each size? But then again, it seems that hinting process is also a laborious process. Is licensing and file size an issue? Are you suggesting that as web designers and publishers we should propose the use of just three type sizes? From a graphic design perspective, this made me think of typographic exercises, designed to teach traditional principles when one starts to study typography. There are many examples of classic typography manuals with exercises based around the restraint of using three type sizes. I am very interested in a discussion about font embedding possibilities for the web and wonder what you think of sIFR? Many thanks for an interesting read.
2007-02-04 by Su
sIFR has its place
sIFR isn't, and probably never will be, intended to be what font embedding would be. It's great for headings or snippets(say, pullquotes), but while there's nothing stopping you from applying it to body copy, it'd probably be a really bad idea. It should also be noted that sIFR v3 has been in fairly quiet development this whole time, and a <a href="http://novemberborn.net/sifr3/beta1">first beta</a> was posted around mid-December, as it addresses several limitations of the previous.
2007-02-05 by Berlow
Thanks for the ?
sIFR as fr as as I can tell, is just a copying technology that treats type, (like flash does), "just like a graphic", which is type loose from the rhythem and color that I'm speaking about. The best analogy to what's being done there, in quartz, cooltype and cleartype, is the sampling of a movie at some number of varying rate different from the 24 frames per second that it was made at, and then, compressing the resulting sampled frames and attendant sound into a shorter piece of work. If you know the movie, you could probably follow along, but for first time viewers or people interested in the details, it'd be a pretty hard to get the plot. And, it's be whole different story, so to speak, if the original director was asked to remove frames and sounds selectively, rather than by mechanical sampling. A much subtler form of confusion sets in when the type is poorly sampled, I believe.
2007-02-18 by John D. Berry
Using it now
David, I can't figure out how what you're proposing would work in practice. How would I put your fonts to work, other than on my own system to read my own e-mail? How would you implement this, say, on a website like this one? It's a little bizarre to be reading about screen legibility when the actual text is reversed out against bright, bright red, and it's justified with no hyphenation. (Roger, what were you thinking?) It's actually quite hard to read. Even a better font wouldn't change that.
2007-02-21 by David Berlow
So?
John, thanks for the great question. Just fixing the fonts for yourself is not enough? I thought that was my job, lol. Then there is the larger "myselves" where fonts can be controled one can fix up nice type for groups of users. In addition, readers, pdfs, and other font transports can bring higher typographic quality to bear with this method. These, in some cases, are subtitutes for what some think is the lagging pace of html's typographic capabilities. For that, you have to look elsewhere. The last time I saw a w3c presentation on fonts, the spokesman for that organization stated to the effect that "the network has to take care of the problem" (with the problem being fonts). If that is the case, the way to network a solution is for the html to be able to contain more than just a font name and size, and in fact to allow an url to a font according to the user's needs in great detail. Once it needs to do this, it should also contain all the information currently supplied by the user's OS to complete the font's specification and with the html present the type to the user. Currently, with just a font name and font size specified, and assuming a modern OS, the user's OS takes it from there, determining if the font is installed (which in itself is information about the script, language and font format requirements), the OS substitutes if the named font is not present, but in any case then scales the required characters to the correct size and presents them to the rasterizer to be filled and sent to the screen. If the html can contain all it needs to seek and specify, build an url for the whole type specification if required to the letter(!), send it to the url to be filled by the proper fonts, then type can move around and bring its magic to design on the web, can't it, please? The url-to-a-font should be next, and if "the network is going to take care of the problem", that url will be a complete font specification. So, there is no reason not to get a little ahead, while still serving fonts to those who can and wish to benefit from the improvements. Cheers!