Readable Web » @Font-Face

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...]

Amazon Moves To HTML5/CSS3 For New Kindle, Leaves Mobi Format Behind

Richard Fink — Fri, 21 Oct 2011 15:50:10 +0000

Some folks I know are waiting for E-Pub to magically arrive and provide a comfy transition from print to screen. But anybody who’s looked into that closely knows it’s a fairy tale.

Ain’t gonna happen, and here’s the latest nail in the E-pub coffin:

Kindle Format 8

The List of Features Includes @Font-Face

Here’s a list of supported features on the way:
List of supported HTML tags and CSS elements

(Note to Amazon: It’s HTML Elements (but I’ll accept “tags”) but definitely not “CSS elements” CSS Properties, it is.)

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.

ttfautohint – Support Web Typography

Richard Fink — Wed, 10 Aug 2011 14:10:43 +0000

There is a very promising open source tool by developer Werner Lemberg called ttfautohint which promises to make it a lot easier for font designers and also web designers working with free, open-source, and public domain fonts to get them looking good on Windows. Even the early versions have some experts in font software sitting it up and taking notice.

Help Improve Web Typography with ttfautohint is a quick and entertaining video explaining the problems ttfautohint is trying to solve.

Send Money

I’m kicking in a few bucks, and you should, too.

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.

New @Font-Face Syntax: Simpler, Easier

Richard Fink — Mon, 07 Feb 2011 17:51:59 +0000

I love it when a plan comes together.

Some months ago, in an an email exchange with Jeffrey Zeldman about the feasibility of a book about web fonts, I wrote that the turning point – the point at which enough would be known to establish best practices – would be around the time IE9 and Firefox 4 were released to market.

A Simple And Conformant Cross Browser Syntax

Now, with IE9 and FF4 nearing release, as if on cue, Ethan Dunham of Font Squirrel has revisited the problem of a cross-browser CSS @Font-Face syntax and found – a year and half after it first became an issue – a new and simpler solution. This was last Thursday.

Only on the web could change happen so fast. Knowledgeable eyeballs were on it immediately. And within hours of publication, it was tested and tweaked a few times. By the end of the day it was already being implemented at Font Squirrel, Font Spring, and Kernest, too.

It Comes In Two Flavors

Since one of the things I do like about the Mo’ Bulletproofer syntax is that, while the following is conformant:

     src: url('http://:/') format('no-ie-404')

it’s obviously odd and deliberately self-describing. Therefore it’s less likely to be left out once you’re in the habit of using it. And less likely to be deleted accidentally by someone unfamiliar with it’s purpose. So, the following is my version of the new syntax, in line with that practice. It’s the result of tests done with the IE9 Preview 7 build and many other desktop browsers and platforms over the weekend.

The Trick Is In The Question Mark

There are currently two variations. They are:

@font-face {
     font-family: 'fishyfont';
     src: url('fishyfont.eot?iefix') format('embedded-opentype'),
	   url('fishyfont.woff') format('woff'),
	   url('fishyfont.ttf')  format('truetype'),
	   url('fishyfont.svg#svgFontName') format('svg');
	}

With this variation, IE 6, 7, 8 and IE9 take the EOT file. But, of course, IE9 supports WOFF, too. So what if, for some reason, you want IE9 to take the WOFF file instead?

Follow The Bouncing Ball

Well, the ball that was set bouncing with Ethan’s original post on the Font Spring Blog bounced back again from Melbourne, Australia where Ryan Seddon of CSS Ninja posted a fix that overcomes this limitation:

@font-face {
     font-family: 'fishyfont';
     src: url('fishyfont.eot?iefix') format('ie9-skip-eot'),
           url('fishyfont.woff') format('woff'),
           url('fishyfont.ttf') format('truetype'),
           url('fishyfont.svg#svgFontName') format('svg');
	}

With this variation, IE9 will not take the EOT. Instead it takes the next font in the stack that’s in a format that IE9 understands. In this case the WOFF file. If there was no WOFF file, it would take the TTF. (That is, as long as the TTF has the hidden embedding bit set to “Installable” – if Microsoft is still sticking to that. I’m not sure what IE9 does in that case, we’ll see.)

It’s Still Being Tested

There’s no such thing as too many tests or testers. If you find a problem, please report it on the Font Spring Blog. Or here.

I’ll be posting more as I test more and to explain how and why all this works and what problems it solves.

Update: Feb 17 2011

Alert: In some quick-and-dirty tests of this syntax in IE9 RC1, a problem came up. If the page kicks IE9 into a “less than” IE9 Compatibility Mode, this technique fails and the fallback font displays. The word from Microsoft’s IE team is that this behavior will not be altered for IE9 RTM.

[Let's get it over with: insert, mentally, your expletive of choice here and now, and then let's move on....]

What this means is that, as of right now, the most comprehensive, failure-proof method – one that avoids the bug in Android, the innate strangeness of the local() descriptor, and bridges the gap between IE6, 7, 8, and IE9 – is the Mo’ Bulletproofer @Font-Face Syntax. However! However! If you prefer a single declaration solution and your pages don’t trigger one of the IE9 Compatibility Modes, barring any more unforeseen changes between IE9 RC1 and IE9 RTM, the Fontspring syntax seems alive and well. The problem won’t come up. Note also, that you can near-totally prevent failure and ensure your pages are running in IE9 “Edge” mode by using the X-UA-Compatible Meta Tag.

Update: March 02 2011

Alert: More changes, but I think we are finally at the end. Maybe. Ethan Dunham has “hardened” the syntax by adding in the EOT-only src descriptor that was a part of Paul Irish’s Bulletproof Syntax. And it works in IE9′s compatibility modes, too. (I can’t see a downside. In fact, adding that first EOT-only src descriptor was Microsoft’s recommended approach to bridging the gap between IE 6, 7, and 8′s proprietary implementation and IE9′s standards-based implementation from the very start.)
So, the following now works universally:

@font-face {
	font-family: 'fishyfont';
	src: url('fishyfont.eot'); /* IE9 Compat Modes */
	src: url('fishyfont.eot?iefix') format('eot'), /* IE6-IE8 */
	     url('fishyfont.woff') format('woff'), /* Modern Browsers */
	     url('fishyfont.ttf')  format('truetype'), /* Safari, Android, iOS */
	     url('fishyfont.svg#svgFontName') format('svg'); /* Legacy iOS */
	}

Ralf Hermann is recommending it in an article on @font-face at Smashing Magazine.

Is it rock-solid? Looks like it. I would use it. But only IE9 RTM can seal the deal. Or not.
Stay tuned.

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.