Readable Web » Fonts

Practical Font Design, Third Edition

Richard Fink — Thu, 01 Dec 2011 17:29:12 +0000

In Digital Publishing you need to co-ordinate your efforts with many people. Web designers, developers, server techs – the list goes on and on – and the more you know about how those people go about their work, the better off you will be.

With fonts, the “collaboration” might take the form of a purchase, or a free download, or just a link to the font in your HTML. But there is a font-maker somewhere on the other end of that transaction. And the more you know about how that font came to be, the better off you’ll be. And unlike a lot of things in today’s fast-paced environment – where it’s hard to separate the side-shows from the main attractions – a knowledge of fonts and how they’re made won’t be obsolete in just a few years. Changes in font technology come at a snail’s pace, and what changes do come, are incremental. So what you learn about fonts will pay dividends for as long as you live. Really.

Have A “Practical” Christmas

David Bergsland’s Practical Font Design is now in its Third Edition. It’s greatly improved in many, many ways from the Second Edition. (Bergsland not only listens to reader feedback, but he acts on it, too.) It’s still the only book of its kind, and it does a simple thing: it tells you, in a friendly and to-the-point manner, how one experienced font designer and teacher – David Bergsland – goes about his work. It’s a must-buy for font designers. It’s a should-buy for any web designer, graphic designer, or anybody involved with digital publishing.
Not much interested in the technical details? – It’s worth the price just for the “history of type” section and as a flip-through reference. If you’ve ever used Adobe Illustrator or CorelDraw, you already know more than you necessarily need. And a demo download of FontLab Studio – the professional level font editor referenced in the book – is available for Mac and Windows free.

Here’s a little piece to give you an idea of the tone:

“My plan is to go through my decision making process so you can do the same as you develop your fonts. There is no right or wrong here. All you have to guide you in the process is your personal sense of style – what’s right and wrong.”

Practical Font Design, The Links:

Amazon Print and Kindle

Lulu PDF

Lulu Paperback

David Bergsland sells his fonts at:

Hackberry-Fonts

And blogs here, dispensing technical tips and helpful font-making tools:

Hackberry-Fonts Blog

Extensis Brings Google Web Fonts Straight Into Photoshop

Richard Fink — Mon, 07 Nov 2011 23:42:10 +0000

Extensis, the company behind the WebINK web font service, today announced a plug-in that brings Google Web Fonts straight into Photoshop.

Free And Open-Source Fonts Served Alongside The Proprietary, In A Surprising Twist

Since launching the WebINK web font service, Extensis has concentrated on building a library of fonts drawn from the proprietary type community, building on long-standing relationships developed through Extensis’ other font and design products: Suitcase Fusion (a desktop font manager) and Universal Type Server (a server-based font library and font license manager for workgroups).
But they haven’t left it at just being another service operating in the shadow of (now Adobe) Typekit – as services like Fontdeck, WebType, and others have done. From day one, I’ve personally seen them strive to find new ways to meet the needs of web designers with innovative software tools that, in combination with their hosting service, make the use of a font service – as opposed to shopping the web for suitable fonts and then self-hosting – a much easier and useful proposition. They’ve continuously shown up at the major web conferences to promote, of course, but also to watch and learn and listen. What’s sets them apart is that they turn around and act on that knowledge in creative ways.

Riding Piggy Back On Google’s Web Font Initiative

[A developing story... more analysis, riding in on piggy-back, is on the way...]

Steve Jobs Role In Typography By Computer

Richard Fink — Mon, 17 Oct 2011 16:21:37 +0000

A few weeks ago, my eye doctor said to me, “I only know of two people who know anything about fonts, you and Steve Jobs.” Seemed Dr. Patel was re-doing his web site and had questions about the qualities of Trebuchet MS. But the line about Jobs raised an eyebrow, naturally, and it was as I suspected – Dr. Patel had read Jobs’ commencement address to the Stanford graduating class of 2005, the relevant portion of which follows:

“Reed College [where Steve Jobs enrolled for awhile] at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn’t have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can’t capture, and I found it fascinating.
None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, it’s likely that no personal computer would have them.

Setting The Record Straight

A lot of people know that Benjamin Franklin did research on electricity. The silhouette of Franklin in a lightning storm with his kite flying and key dangling is emblazoned on the average American’s brain: the rugged individualist in pursuit of a dream, no matter the danger. But what almost nobody knows is that Franklin’s work on electricity was as a part of a team of co-equals. And that his signature was only one of several others’ that appeared upon publication of that work. But Franklin had the fame and got the credit. Sound familiar? History is a single-sentence thing.

A lone eagle, as an icon, works great. A flock of geese, not so much.

FinksLinks: Pre-Approved For Your Reading Pleasure

Here’s a couple of articles to help put it all in perspective:

The Impact of Steve Jobs on Typography

Steve Jobs and Type: Connecting the Dots

And here, on Typophile.com, a bit of additional insight, debate, and perhaps a few ruffled feathers: Steve Jobs 1955-2011

Adobe Announces Acquisition Of Typekit

Richard Fink — Mon, 03 Oct 2011 19:43:00 +0000

It’s fair to say that those close to the development of Web Fonts expected Typekit to be acquired by somebody. Well, today somebody did.

Adobe Buys Phonegap And Typekit for Better Web Tools

The Typekit Blog Announcement

And Adobe’s press release: Adobe Acquires Web Typography Innovator Typekit

A good thing? A bad thing? An inconsequential thing? Who knows?

A Nice Use Of Web Fonts In Mainstream Media

Richard Fink — Fri, 09 Sep 2011 00:16:10 +0000

There’s a nice use of web fonts at the New York Times. (Just remember to clear your cookies to keep on reading past their twenty page a month limit.)

Titled The Reckoning , it’s a link and teaser page for a group of stories about 9/11.

Very tasteful and dutifully solemn.

Definitely not cheesy.

We don’t want cheese.

Worth a look. Really. Except for the upper case “G” with a pimple on its chin. Is this some kind of slick reference to Lincoln? Or Lincoln’s well-documented love of pizza? We’ll probably never know for sure.

A Webfont Specimen Page Free For Download

Richard Fink — Sun, 10 Jul 2011 15:53:36 +0000

Tim Brown of Typekit put together a webfont specimen page awhile back. Originally introduced in Tim’s article for AListApart: Real Web Type in Real Web Context, and it does give a real nice view of a font in a variety of contexts.

I’ve incorporated a modified version of it into my suite of web font test pages. And, for those who might find it useful, you can take a quick look at it here, and download it here.

The Modifications

There’s two main differences between my version and Tim’s:

For test pages, I like to keep everything – the HTML, CSS, JavaScript, and even images – contained in a single file. As my webfont test pages have evolved, I’ve just found it simpler this way. At least to me. So everything is in one .htm file. The two images from the original – used for background – are included as Data URIs in the CSS. The only downside is that those images won’t show up in IE6 or 7: a situation that doesn’t bother me because nearly all the functionality remains intact and my IE testing is usually done on IE8. (IE6, 7, and 8 all require EOT, and Windows GDI is the rendering engine for all, and I’ve yet to see a font problem appear in IE6 or IE7 that didn’t show up in IE8.)
The @font-face syntax has been updated to use the “Fontspring”, single declaration syntax.
See: Further Hardening of the Bulletproof Syntax and Best Practices for Serving Webfonts to IE9 on the Fontspring blog for more information.

Pause Before You Say “IE Sucks”

An interesting glitch appeared while I was working on this. When displaying the font Ultra from Google Webfonts, there was a strange difference between IE8 and Chrome. In IE8, the glyph “j” was clipped off on the left like this:

But Chrome rendered the entire glyph and allowed the part that IE clips off to extend outside the bounding box to the left:

In both cases, it’s not what you want.
Which browser is doing the technically correct thing? And more importantly, what’s causing it? Since the clipped “j” in IE was more of an eyesore, the kneejerk response for most developers would be, I think, “Goddam IE! Again!”. But after opening the Ultra font in a font viewer, the real source of the problem revealed itself.
In the font itself, the position of the left sidebearing of the “j” was the source of the problem:
You can see that the font itself “clips” the “j”. (And this may or may not show up depending upon the layout.)

Over the past eight months I have cracked open many hundreds of fonts, one after the other. And I can tell you firsthand that even on carefully made fonts, stuff like this happens a lot. Ultra was designed by Brian J. Bonislawsky of Astigmatic who’s very experienced. But even so, stuff happens. So, before you go blaming the browser, if you’re using a webfont, remember that a new variable has been added to the mix – and the source of what seems like “buggy” behavior is just as likely to be there as anywhere else. Just what web developers needed, a new complication!

Some Cool Tools That Came Into Play

The CSS for Tim Brown’s page was originally in three separate CSS files. I brought them together within a single style tag using a nifty free tool – CSS Mixer – which allows you to select a bunch of CSS files, concatenate them into a single file, and minify the code using the Yahoo User Interface Library. After that, it’s cut and paste. Very handy. There is also a tool by the same developer, Sam Beauvois, for concatenating and minifying JavaScript named JS Mixer. (They’re .NET executables for Windows only. No Mac or Nix versions unfortunately.)

That’s it. Pay it forward.

Best Practice For @Font-Face CSS Takes A Turn

Richard Fink — Mon, 31 Jan 2011 13:32:50 +0000

“Bulletproof ” is out, and “Mo’ Bulletproofer” is in.

In the last few days, major players on the web fonts scene – Kernest and Font Squirrel – have moved from Paul Irish’s Bulletproof @Font-Face syntax to Richard Fink’s Mo’ Bulletproofer syntax as the default.

Ethan Dunham, the developer behind Font Squirrel and Fontspring says:

Mo’ Bulletproofer is the only syntax that works across browsers including Android.
IE and Android both have buggy implementations and this format works around both of them.

Since I’m Richard Fink and this could just be my ego talking, here’s why Mo’ Bulletproofer is best practice going forward…

The Android local() Bug

Android has a bug that’s triggered by using the local() descriptor inside the @font-face declaration.

To clarify, the following non-standard code does not work on Android as it does in IE 6-8:

@font-face {
  font-family: 'somefont';
  src: url(somefont.eot);
  /* IE takes this font, Android doesn't. */
  src: local('3ix90a'), url(somefont.ttf) format('truetype');
  /* Android chokes on the local() descriptor and
    discards the entire @font-face declaration.
    No web fonts show up. */
   }

Unlike IE, Android doesn’t “look back” and take the font specified in the initial url reference.
This makes the “Bulletproof ” syntax unusable on Android.
The problem is described in a bug report filed by Google’s Paul Irish, originator of “Bulletproof ”.
It also includes this FYI:

This bug has also caused a workaround from the Google Font API team: http://code.google.com/apis/webfonts/
As a result they sniff and change the CSS they serve to Android 2.2 devices.

Android Is Too Big For This Problem To Go Ignored

There isn’t much choice here. Mo’ really is more bulletproof. Even if the Android problem didn’t exist, there are other solid reasons for using Mo’ , but Android is the kicker.
How big is the Android market? Well, in 2010 Android emerged as the single best selling mobile platform in the United States.
Andy Rubin, former Android CEO and current VP of Engineering at Google, reports that 300,000 Android devices are being activated every day.

Bulletproof Reported As Problematical On Linux, Too

Last week there was a pingback here at RW from WordPress developer Aaron James Young saying:

I use the Mo’ Bulletproof @font-face syntax, which I’ve found to have the best cross-browser compatibility.

Young spent considerable time hands-on, testing Linux based browsers, before coming to this conclusion.
(It seems GTK-Webkit and Konqueror also have problems with local()).

Don’t Use local() At All

The bottom line is that using local() at all is a bad practice. In Google Fonts Failing for Internet Explorer Users I wrote:

See Jonathan Snook’s post here, and this Typophile thread here for an in-depth explanation of why the local() descriptor should not be used to specify a locally installed font except in very special circumstances.

I now take part of that back: in the absence of being able to specify and query for a unique font version ID – as a matter of defensive coding – I can’t imagine a plausible scenario where using local() isn’t, in some way, asking for trouble.

Here’s the original post on Mo’ Bulletproofer. To be updated soon, after the next Beta of IE9 arrives for testing.

Update – Feb 3, 2011

Paul Irish has chimed in on this issue in the comments. See his roundup on full view, with web fonts, on this test page. Paul is reporting that IE9 downloads both the EOT file and the WOFF file using Mo’ Bulletproofer. His tests were performed in Platform Preview 7. Is it a bug or a flaw in Mo’ Bulletproofer that calls for the addition of Conditional Comments? (That would fix the problem and it’s likely that the page would already contain the necessary “less than” IE9 Conditional Comment tags, anyway.) Also, in yet a new turn, Ethan Dunham of Font Squirrel has chimed in with yet another syntax that looks quite promising. And clever, damn him. Stay tuned. Rumor has it that IE9 RC1 (or will it be an RTM?) is due out in just a few days. Will go hands-on with testing then.

Google Fonts Failing For Internet Explorer Users

Richard Fink — Mon, 10 Jan 2011 15:39:13 +0000

If Google isn’t going to take web fonts seriously, they should stay away. Slapping on a “Beta” label doesn’t excuse sloppiness or, worse, pursuing a hidden competitive agenda at the expense of users and developers. Now, I can’t know if Google Fonts is shortchanging IE users intentionally, but in light of the controversy over, say, Chrome Frame, you have to wonder.

Here’s what’s going on:

Jerrold Maddox, art professor, teacher of new media design at Penn State University, and a fellow member of ATYPI, sent me an email last Friday asking why an italic font – being served by Google – wasn’t showing up on his iPad.
( Jerry’s heavily into HTML as a platform for ebooks. The book that prompted his question, is here.)

The font is OFL Sorts Mills Goudy TT which comes in a Regular and an Italic. First, I looked in Internet Explorer. (IE users are still, conservatively, 60% of browser users. And yes, I am one of the great unwashed.)
Well, the italic wasn’t showing up in IE, either. IE was synthesizing the italic. In fact, on the specimen page for the font at Google, IE synthesizes it there, too. You can take a look.
What’s going on?

As it turns out, if you specify both regular and italic members of a font-family, Google doesn’t send more than the first one, the Regular, to IE. This is by design, not a malfunction. A quick test of two other fonts – Droid Serif and Tinos – gave the same result. And you can see it on the specimen pages.

You can test this by inserting this line into your style sheet:

@import url(http://fonts.googleapis.com/css?family=OFL+Sorts+Mill+Goudy+TT:regular,italic);

Alternatively, keying the URL into the address bar will show you the CSS being inserted by the @import declaration for the particular browser you are using.

Google fonts does not insert the CSS for the italic when it sniffs Internet Explorer. In fairness, I scoured the Google Fonts API documentation for any description of this behavior but there was nothing.
Internet Explorer has supported the use of font-families for over ten years. It’s well documented at EOTFAST. I know because I wrote it. (BTW – EOTFAST will soon be upgraded to include an EOTFAST 2.0. Plus additional tools and expanded tips and documentation. Stay tuned.)

Beta Not Use Google Fonts, Because There’s More Wrong

I wish this was the only defect in Google’s font effort. It isn’t.

Ordinary characters may be missing from the font:
For example, the font Tinos is missing something as basic as a semi-colon. And yet, the character list leads you to believe that it’s there. (If you look at the character list closely, you can see that the style of the colon and semi-colon are different. It’s probably the fallback font peeking through.)
Here are screenshots:
FontLab shows the missing glyph.
See the difference?
Google’s CSS Syntax Can Mess You Up:
Best practices are being ignored. See Jonathan Snook’s post here, and this Typophile thread here for an in-depth explanation of why the local() descriptor should not be used to specify a locally installed font except in very special circumstances. (Normally, it’s used as a mask to prevent unwanted http requests in IE.) The Tinos font is the perfect example of why this is so.
Scenario: Maybe the developer wants to make some complimentary images in Photoshop using Tinos and installs this version of the font – without the semi-colon – in the operating system. Well, unless you’ve figured out a way to push down font updates from the browser into the Windows fonts folder, with the CSS syntax as it’s now being delivered, forevermore on that developer’s machine, Tinos will continue to appear without a semi-colon. It will not have been updated with the fix.
Message to Google Fonts: if you’re going to take a “we’ll fix it later” approach, please think through how and to whom those later fixes will be delivered. And if delivery is even possible except by Federal Express.
The font may contain unhinted glyphs: For example, the ASCII characters in Sort’s Mill Goudy are all hinted and look OK in the Windows GDI rasterizer. But many, many of the non-English glyphs and all of the Small-Caps apparently, are not hinted. If your web site is in French or Spanish you may be in for a whole lot of ugly.

It’s A Matter Of Trust.

This is Google, not a font services start-up out of nowhere. Developers are still very much strangers to using web fonts and @font-face and when Google brands an effort with their name, that creates expectations. Dabbling – just dipping a toe in the water – without the seriousness of at least some minimal quality control or, in the absence of that, some additional caveats and added transparency, is not a contribution. It’s just messing with people’s heads. And some fine-print disclaimer somewhere doesn’t change that.
I trust Google for Analytics and all kinds of other things. I am a great admirer of the Google Books project. And Google, the company, in general. But for web fonts today? Fuggedaboutit!

And, oh, BTW – the italic wasn’t showing up on Jerry’s iPad because he hadn’t as yet upgraded to the new OS with support for web fonts in the TrueType format.

Case closed.

Kernest’s Konstellations

Richard Fink — Tue, 21 Dec 2010 03:44:49 +0000

Here’s a unique Christmas gift idea for the web designer you love.
Web designer Garrick Van Buren – the man behind the web font service site Kernest – is offering a new way to explore web fonts and web typography using a template based approach. It’s called Konstellations.

Konstellations: A Way Into Web Fonts

Each month you get a whole web fonts feast for your inspiration, education, and delectation. Custom designed by Garrick to show @font-face at its best. And complete with everything you need to dig in – the style sheets, the fonts, and the HTML. Want a taste? Lookee here.

Garrick has a unique aesthetic sensibility and I’m greatly looking forward to seeing what he comes up with each month as the subscription moves on.

Sound Good? Want To Know More?

Check out Unmatchedstyle.com for a video chat with Garrick along with review of Konstellations and Kernest.

Web Font Follies

Richard Fink — Thu, 09 Dec 2010 20:10:22 +0000

I freely admit that typographic subtleties like Old-Style Numerals and Swashes don’t send a tickle up my leg. I’m not alone in that. Most web devs wouldn’t give a rat’s ass about those things even if they knew what they were. I asked one web developer if a font with just the Latin-1 characters was okay and he said, “I don’t think so, the site is for a Presbyterian organization.”
And kerning? Don’t get me started… text on the web got by without kerning for fifteen years and all it’s done is grow, grow, grow. Kerning could be bad mojo. Why take chances?

The Web Font Revolution Is Just Beginning

Stephen Coles, formerly of FontShop recently wrote a blog post titled The Webfont Revolution Is Over, Let the Evolution Begin that left me with the feeling that somebody I know needs a good kick in the rebuttal department. Now don’t get me wrong: I liked a lot of what Stephen had to say. And I’ve written similar stuff myself.
But I take issue with a few things. So here goes:

“Like Simon Daniels said so prophetically over a year ago, the war (over formats
and security and delivery) is over.

The War Over Formats And Delivery Is Not Over

Microsoft doesn’t support Data URI’s except in its own IE Fourish, boorish way. And Microsoft is, so far, enforcing the DRM embedding bits within TTF files in an attempt to cling to its cake and eat it, too.

“See? We support raw fonts just like the other browsers!”
(Except in the way we don’t.)

Opera, Safari (on Mac and now iPhone and iPad), Firefox, and Chrome all support TTF without enforcing any DRM restrictions. But in IE9 it lurks as a hidden gotcha. It will waste incalculable hours of development time as web authors go around scratching their heads wondering, “Why isn’t the font showing up in IE?” (This happens to me all the time, still. Go download a fresh copy of the open source Liberation fonts from Red Hat and see how the embedding bits are set.)
IE9 will reject those fonts.
And when the web author finds out why, it’s only a kick in Microsoft’s pants, nobody else.

When will the king stop meddling with trifles? Just when, oh when, are we finally going to put to rest the phrase, “Fucking Internet Explorer”?

“Things will get better. Display pixel density will improve. Windows users will upgrade, replacing GDI with DirectWrite. But this evolution will be slow, and we can’t do much to speed it up.

The Pace Of Change Will Speed Up, Not Slow Down

Nothing is going to move slowly where e-publishing with HTML5 is concerned. The promise of DirectWrite remains “of the future”. DirectWrite doesn’t get anybody off the hook for doing nothing about the visual quality of fonts and their usefulness to developers now, today. Why not just admit that the type industry – and I include me in that – was caught sleeping and stop making excuses?

Now, if by “evolution” it’s meant that the development and deployment of web fonts from here on in will proceed in a slow, steady, controlled, and measured pace, that will not happen. I know it’s hard to see from where and from whom the answers will come, but they will come. If there is a demand, someone will fill it. And it will be frantic. E-Publishing is about to explode and Flash as a text replacement technique is dead.

“Demand comprehensive previews that show fonts in multiple sizes in all the most common rendering environments

Don’t get me started, I said.

Bah, Humbug!