Practical Font Design
2nd Edition For Fontlab 5
If you’re looking for a brief, straightforward introduction to fonts, I recommend David Bergsland’s Practical Font Design. Unlike a lot of books that make you feel like you’re seated in the back row of a crowded lecture hall, this one feels like a private tutorial.
Bergsland takes you inside his studio, sits you down, and talks you through the basics. It keeps to a schedule, too: no bullshit.
If you’ve gone looking for information about fonts, you may have noticed that there’s a lot of information about typefaces but not much about the technology of font-making. And what info there is, is scattered piecemeal here and there. And most of it is decidedly not for newbies, either. So unfortunately, in the field of fonts today, it doesn’t take much to stand out. That said, this is still a good book, and I wish there were more like it from other designers, offering other perspectives. There’s also a newly published Practical Font Design:Part II, that I’ll be buying, as well. In it, Bergsland describes, in detail, the creation of a nine font serif font-family and a companion sans serif.
Fink v. Bergsland: What You Won’t Find In The Book
Before web fonts and the explosion of e-reading devices like the Kindle, the iPhone, and the iPad, nearly every font designer on earth was concerned exclusively with how their fonts looked in print. And most days, it still seems that nearly every font designer on earth is concerned exclusively with how their fonts look in print.
I work with fonts a lot. And I’m concerned almost exclusively with how they look onscreen, in web browsers. And so I ask myself sometimes: “Is it me, or is the world crazy?”
In the book, Bergsland has this to say:
“Do I use hinting? NO: Hinting is the minute adjustments to outline position and size to make the font more readable on the screen at small sizes. I do not design fonts for the screen. There are companies that specialize in this minutia. Ascender Corp is the most famous. They design the fonts for Microsoft (among others) including fonts like Verdana, Calibri, and many more. I just hit the Auto Hinting command before I export the fonts (if I remember). I know. I should be more responsible. Right? But it really does not matter for my purposes. A font that reads well on the screen is far too heavy and clunky to be used in printed books.”
Now, note that this book was published just this year – in 2010. So my initial reaction was: where has this guy been for the past year and half? Under a rock? How relevant does he expect his “purposes” to remain as time goes by?
But wait, there’s more:
“I really could care less about TrueType at this point. I export those formats for both operating systems (Mac & PC). but I just do it as a service to possible customers. I really don’t support this archaic format.”
Ok, so let me get this straight… you, Bergsland, focus exclusively on fonts to be printed with ink on dead trees. But the TrueType format – which, no matter how much teeth gnashing it causes at Adobe is still the dominant and technically superior format for the screen – TrueType is archaic? Yeah, I guess you’re right. What kind of lowbrow weirdo would read from a screen anyway? No future in that, obviously. Stop it right now! And Håkon, pack up your CSS stuff ’cause according to this guy, it’s time to pack it in.
BTW, I’ve heard “archaic” aimed at TrueType before – from a well-known type designer, too. It must be a talking point making the rounds.
Web Fonts, Print Fonts, Beggar Man, Thief
I’ve felt for quite some time – never otherwise, actually – that the whole rigmarole about fonts on the web exposing font designers to easy piracy was based on a number of dubious premises. One premise being that fonts designed for print could just be slapped up on web servers and that would mean prices for print fonts would drop because, heck, why pay for it if you can browse around the web and cherry pick endlessly with no price tag attached? (There’s huge flaws in that scenario from the get go, but let’s leave it alone.) Well, David Bergsland obviously believes there’s a divide between fonts for web and fonts for print. Me too.
Others, as well. I recently found myself re-reading the following from a blog post in 2009 by a guy named Yves Peters:
“With some notable exceptions, modern typeface families are print tools. The designers of them spend three weeks in a cubbyhole creating hundreds (or thousands) of kerning pairs because they’re being used at 1200dpi, not 75, 85 or 100dpi (or whatever nominal DPI rate your OS uses). Those traps he or she slaved over aren’t going to be worth a damn on your LCD, whether it be a lowly eeePC or a Mac Pro, as they’ll be displayed at 11pt on a browser who’s developer didn’t give two hoots about its type rendering capabilities. And you can kiss goodbye to those subtle shifts in line contrast, or those delicate little serifs. Those hairlines will recede faster than Ian Hislop’s before a high court judge.”
Minus the swipe at browser developers who don’t care about type rendering capabilities, quite true, I think. Even as screen resolutions improve – like the iPhone’s Retina display – it will still largely always be true. Luminescent screens will never be like paper and ink. There’s no reason to think that they should be. And the reason I spend my time almost exclusively on fonts for the screen is because the sooner we don’t have to use ink on dead trees because there’s no practical alternative, the better off we will be.
Lastly, a tip: in one chapter, Bergsland writes about testing fonts – testing meaning printing them out, of course – and of the need to keep re-installing them in the operating system as they evolve.
This is surely outmoded. In my experience, HTML pages using print style sheets with the font-sizes specified in pt (to get the point sizes in between the pixel sizes) will suffice for the bulk of testing.
I test fonts in browsers all day. I’ve never installed a font for testing purposes yet.
But if it’s an OTF or TTF and you’re using Internet Explorer 9+, make sure you set the embedding bits to “Installable”. The wise folks at Microsoft are making that a precondition, for some stupid reason. Ahh, but then again, Bergsland’s book says to set the embedding bits to installable right from the start! I guess he didn’t get the email from Redmond. Or else maybe he’s one of those libré free-the-font commies. Anyway, the book’s certainly worth the 13 bucks. IMHO.
{ 5 comments… read them below or add one }
Your points on my attitude to Web fonts are certainly valid. I’m currently producing all my new fonts in OTF and TT. I’d wouldn’t mind making them fully hinted, but having a severe coding handicap has put me off severely. I get lost in the geek speak real fast. I’ll go there as soon as I can figure out a way to do it without a lot of coding.
David! I was wondering when and if I was finally going to hear from you. I’ve been doing a lot of work with hinting without the geek-speak – you’ll hear from me about it in the near future.
Is the new book on Amazon yet? Or should I buy the Lulu version?
The Lulu version is usually printed better.
I’m working on a radically revised 3rd edition. What do you recommend I say about hinting and TrueType? I will be recommending generating TTF and OTF.
Most of my customers are still print designers, but I need to leave the options open.
Email me privately if you like.
(Might email you separately on this, as well. Plus, I’m writing a book and would like your input. Announcement here on Readable shortly.)
The verdict is in: the underlying format for web fonts is TTF.
Just a few days ago, Kernest, the largely free and open-source web font service discontinued serving OTF files. (I believe you’re acquainted with Kernest’s founder, Garrick Van Buren.)
Now, I know type designers are chagrined about this. On their end (and it’s my end too, these days), it’s a time-consuming complication. But for screen output, there is just no getting around it. Microsoft and Apple have spoken. And for the foreseeable future, TTF is it.
TTFs give maximum compatibility. For Windows GDI – in other words, IE6, 7, and 8 – TTF is *required*, period. And, of course, TTFs with decent hinting will always look better. (There’s been more than enough chatter about THAT problem elsewhere, I won’t rehash it here.)
In IE8 with DirectWrite rendering, hinting instructions play a big part, too. OTFs will render, but they suffer from the lack of hinting instructions. Every one I’ve seen in DirectWrite renders less well than a TTF, especially at smaller sizes. (On Mac, TT hinting is ignored and OTFs are indistiguishable from TTFs but at the cost is that fonts in either format become more bold because more pixels are called into play to achieve anti-aliasing.) The iOS – iPad, iPhone, iPod – just started supporting TTF so Apple is now firmly in the TTF camp, too. TTF is well supported on Linux based platforms, too, so it’s a clean sweep.
It’s just simpler to serve TTFs from the web authoring point of view. The CSS @font-face spec has no provision for targeting individual browsers with different formats and having to maintain separate files is a pain. And there is the added complication of having to wrap up the TTF into an EOT file for IE6, 7, and 8 and, if you want to get the benefit of native compression, wrapping it up into a WOFF file.
So, as difficult as it is to swallow, OTF has been marginalized for screen use. All of Adobe’s contributions to Typekit, for example, were converted to TTF. If for no other reason, it has to be this way to satisfy the user base of hundreds of millions of users of IE6-8.
There are always exceptions. On example would be where the author is targeting ONLY the iPad platform. Another would be the inclusion of a print style sheet in the web page. But at the moment, I’m unsure where all the major browsers stand on support for printing with web fonts.
I’ll be ordering PFD Part 2 today!
Regards,
Rich
Hi Richard,
If you would be interested in a PDF of the new book to review, let me know.