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.
{ 10 comments… read them below or add one }
The ‘clipping’ of the lowercase j in Ultra is surely intentional, being a classic example of a kern, and the ‘correct’ display behaviour from a designer’s perspective will always be to show the whole glyph even if it does overhang the bounding box. Otherwise any kerns that reach the left or right hand edge will be hidden, leaving a partial letter behind.
This is an interesting (though not new) layout problem and I think it’s showing up between these two browsers because Internet Explorer tends to prefer to hide content that extends beyond the bounding box almost as if it has added content-overflow: hidden to the attributes for the element concerned.
Hi Ben. Well, I think you’re right about it being intentional. (gonna send Astygmatic an email about this today. Maybe he’d like to comment.) But I don’t know if you can call it a kerning issue because it’s a part of the default spacing. “Tracking” maybe? Me, I would just consider it a general spacing issue. But if there’s a lesson I came away with from this, it’s that in a left-to-right language, left sidebearings that intrude on the glyph can have unexpected consequences. I haven’t checked the CSS specs to see if there’s any UA guidance about this, but my preference is actually for what IE does – preserve the box. And I don’t see how this view is any less from the “designer’s perspective” than what you’ve put forth.
I’m wondering if any of the installed “web safe” fonts, or those in the Cleartype collection have glyphs spaced like this.
Thanks for commenting. Are you aware of any other CSS glitches that seem peculiar to web fonts? I have no doubt we will see more.
It is neither tracking nor kerning, I would call it negative cut-through and it must certainly be intentional. Just imagine the spacing if the left sidebearing were placed to the left of the ball. This condition is nothing new. Clipping in the lefthand margin of glyphs that have negative cut-through has been around for a long time. It would be a step backward to metal days to design glyphs and fonts to the shortcomings of technology.
@jim lyles
“Negative cut-through”, eh? I gotta sleep on that one.
I did email the designer about it. And yes, I’m sure it’s intentional.
Here’s what I’m gonna do. I’m gonna re-space Ultra and see how the “j” fares without it. The web has done nothing but grow like a weed with a half-dozen typefaces and no kerning for over fifteen years. As Peter Drucker famously said, “There is nothing so useless as doing efficiently that which should not be done at all.”
>It would be a step backward to metal days to design glyphs and fonts to the shortcomings of technology.
But glyphs are designed for the quirks of specific mediums all the time. Highway signage. Different print mediums.
Dismissing the natural biases of these different mediums – which can be their greatest strengths, not weaknesses – as “shortcomings” seems off to me.
But thanks for your point of view on it.
Rich
Hi Richard,
The manner in which I spaced the “j” in Ultra with a negative left side bearing is something I do with all my fonts in order to minimize the need for unnecessary or excessive kern pairs. It is part of my standard design process, and I wouldn’t do it any differently.
This type of negative side bearing becomes an even more important adjustment on webfonts, where no kerning is enabled.
To take the left side bearing to the outside of the ball of the j would create an awkward visible gap in letter-spacing, unless the overall tracking of the font was opened up, but that would not lend itself to the look of Ultra.
You’ll find this to be a design feature with a lot of webfonts and desktop fonts, not just Ultra alone. Sometimes it is slight, other times more significant, depending on the letterforms, unless they have very open spacing to compensate for this.
As you pointed out, this is apparently only an anomaly with IE. However, it should be noted that this problem will only present itself if the “j” is the first letter of the first word on a line. Any other typesettings of the “j” will not clip like this.
On a side note: Thank you, Ben and Jim, for beating me to a response on this.
(PS: Not to nitpick, but please update the spelling of Astygmatic to reflect the “i” instead of the “y”…Astigmatic. Thanks.)
Howdy, Brian.
Mispelling of Astigmatic my bad. Will change. And I’ve had the condition my whole life!
>”As you pointed out, this is apparently only an anomaly with IE. However, it should be noted that this problem will only present itself if the “j” is the first letter of the first word on a line. Any other typesettings of the “j” will not clip like this.”
Some observations:
1) Can we know for sure that the absolutely only time this will present behavior that is mysterious to the average web designer is when the glyph is the first letter on the first word of the line?
My instincts tell me this is probably true, but it’s a sweeping statement being made in the absence of evidence, and I’m not ready to concur.
2) I’m not pleased with the glyph popping out of the bounding box, as it does in Chrome, either. And I haven’t tested in any other browsers as yet. So I’m not so sure that IE is the anomaly.
The root problem is the glyph extending beyond the box. And that just isn’t expected behavior.
2) What doubly bothers me is that, should a web designer run into it, a problem like this has no diagnosable cause unless you crack open the font. (You got another way?) And that’s something that makes commercial font licensors rather uncomfortable.
(But gives designers a reason to keep up with Readable Web! Or read Webfonts 101 when it publishes later in the year.)
Usually, it’s pretty easy to figure out why a line is overflowing the box. But usually that’s to the right in a rtl language. But here, it’s overflowing to the left. Even if it only crops up when the glyph starts a new line, it’s going to happen. And I doubt that there are many web designers out there who are going to look at it and say, “Oh, the left sidebearing is probably cutting into the outline, let me find a workaround.” No, they are just going to be mystified. And that different browsers are handling it differently, just adds to the mystification.
Hey, look, I would not vote for this as the Top Webfont Rendering Issue of the year but still, it piqued my curiosity and I think it’s worth some further testing and inquiry.
I’m a little pressed for time, so I’d be very interested to hear from a browser vendor on this. What’s the proper behavior for a UA when this situation occurs? Or is it something that just falls between the cracks somewhere in the specifications?
Thanks for your take, Brian.
rich
Hello, I’m working on my first site ever and managed to bump into this problem right away:), so thanks for the article!
I have a heading that starts with “j”, and sure enough it is cropped in IE8 and sticks out in FF (first I tried several imported “handwritten” fonts, then Monotype Corsiva). I have FontLab, so when I finally thought of looking into the fonts, I saw the glyphs sticking out, but I totally agree with Brian that it’s only natural for fonts to have them.
So, it looks like yet another problem to deal with:) For now I inserted a non-breaking space before “j” and set a negative left margin in ems, and it looks good both in IE and FF, but maybe someone has a more elegant idea? Thanks
Welcome Maria,
Thanks for reporting this. Can you share a link? Love to see it.
As far as “I totally agree with Brian that it’s only natural for fonts to have them” – I still don’t see what problem is being solved by it.
Stupid me.
Unless it’s a graphic arts/print specific thing and I’m not seeing it because I focus totally on screen display. I fixed it in the font where I first discovered it, and after a bit more playing around with spacing, the font seems none the worse for it.
There’s a good case for considering this a “bug”, frankly. Statistically, the “j” in my example is going to end up as the first character of line a certain percentage of the time.
And, if multiple developers and/or contributors will be working on the site – and don’t forget user generated input! – they’ll be totally unaware of the fix you’ve applied.
And no, I can’t think of a more elegant way to fix it using HTML and CSS, either. Different, maybe, but no less clunky.
Regards, Rich
Hi Richard,
I can’t send the link as the site is not online, but I’ll be happy to send you the files by email. Today I noticed that the letter is cropped in IE only when I scroll down the page or when I zoom in/out. When I renew the page it’s fine (not cropped) again.
Best, Maria
Maria,
This is starting to sound like an IE rendering bug. Not something in the font. Using IE8? I’ve seen some odd things….
The only way to know for sure is to crack open the font and check the metrics.
rich