Draft of vertical metrics recommendations for web fonts

raph's picture

I've been trying to get to the bottom of how to best set vertical metrics in web fonts. These issues go way back, all the way to the creation of the TrueType format, which had separate Windows and Mac fields. Setting them wrong will lead to clipping, strange line spacing, and inconsistencies between browsers - sadly very familiar outcomes for people using web fonts. I'd like to make all that go away, and, just as important, make life easier for font designers, so they can just set the metrics and be confident they're right.

To _really_ understand vertical metrics on the web, I created some test cases and tested on a lot of browsers. I also came up with some draft recommendations, generally similar to the ones Typekit has been promoting.

My recommendations, along with the raw source and screenshots from the test cases, as well as references to source materials (many typophile threads were quite enlightening) are here: http://code.google.com/p/googlefontdirectory/wiki/VerticalMetricsRecomme...

That's a community wiki page, and I welcome contributions, as I'm sure people will have more insight. If you've got something to add (and are not a spammer :), let me know and I'll add you. And, of course, I'm hoping for some spirited discussion here.

One of the other things that emerged from my testing is that people should really be specifying CSS line-height explicitly, rather than defaulting to line-height: normal. The actual spacing behavior of the latter is extremely complex and inconsistent from browser to browser. When you specify line-height explicitly, things get a lot better, but baseline positioning can still be wobbly.

And I'm very happy if people have questions, or feel there's something unclear in that document. I've been spending quite a lot of time digging into this and feel it's a good time to spread what I've found more widely.

Santiago Orozco's picture

great, I'll look into this and back Raph.

jasonc's picture

Great work, Raph.

Do you know if any of the (windows) browsers make use of VDMX tables, if present?

Jason C

Si_Daniels's picture

From last summer... http://blog.typekit.com/2010/07/14/font-metrics-and-vertical-space-in-css/ (mentioned at the end of Raph's article but worth a link in its own right)

PabloImpallari's picture

Hi Raph:
Great work!

Check out this FontLab script, witch is supposed to set cross-platform V-metrics
http://www.typophile.com/node/71230

Nick Shinn's picture

Application developers should get together and come up with a consistent standard, rather than each attempting to create some very clever proprietary solution to whatever they think the problem is.

In my opinion, it should be the responsibility of the typographer/document designer to determine whether extra leading ("linespacing") is required for the job in hand, rather than relying on a hodge-podge of automations whose complications will be compounded by type designers' interpretations.

blank's picture

Application developers should get together and come up with a consistent standard, rather than each attempting to create some very clever proprietary solution to whatever they think the problem is.

The only way that’s going to happen is if future font specifications are limited to a single set of vertical metrics. We should be so lucky.

Richard Fink's picture

I've known about variations in line-height/vertical-metrics between browsers and platforms for quite awhile but what I'm finding hard to understand is why this was or is not an issue with the 'web safe' system fonts.

Aren't there the same variations using, say, Verdana or Arial? In other words, is this actually a new problem or just one that went unnoticed until fonts were in the spotlight?

@nick shinn

I think these are honest divergences of opinion about what font data matters the most, Nick. And perhaps an old fashioned bug or two thrown in. Not a shoot out over proprietary implementations.
There's also a lot more collegiality between competing browser teams these days - at least with something like this. So hopefully the wrinkles will get smoothed out informally. Much quicker that way, to say the least.

John Hudson's picture

Nick, system/application developers could come up with a single standard, and a) the existing compatibility issues would still remain and b) at least one developer would interpret the standard differently and produce new compatibility issues.

Jack B. Nimblest Jr.'s picture

Lol, maybe vm are broken because standards org janitorial gents have no way of understanding font, sze and leading as an integrated spectrum of possibilities, through which per font ideals run according to language and line length? Way too complicated... So instead we have the "standard" assumption of 12point masters and 120% leading, 65-character long lines of English, (or all languages, your chouce) and shove the problem on down the line to "the educators".

For a real solution, standard meta data would need to exist that apps and users would a have chance with. Or... you can go with John's idea, that people will just mess it up no matter what'cha do. Or you can go with the idea that inflexible and incomplete solutions are just an honest diversion of opinion, and not a partial understanding of the complex that is typography today. Or you can take the truly stupid road and think one set of values would work.

See, lots of choices;) welcome to type Tartarus!

raph's picture

@jasonc: I don't know of any such browsers, but I haven't wrapped my head around vertical writing scripts yet. What I'm talking about here is strictly clipping, baseline position, and line spacing for horizontal modes.

@Richard Fink: They are a problem with system fonts - I found clipping for Vietnamese glyphs in Arial on Windows, and inconsistencies in line spacing from Windows to Mac. But I think the diversity of web fonts brings out the problems more acutely.

@dberlow: I'd love to see actually useful metadata in the font that helps apps come up with better layout choices. I think maybe the closest thing we have to that is the "actually use typo metrics" bit, which is a pretty strong signal to apps that the typo metrics are trustworthy. Unfortunately, only IE7+ and recent-ish versions of Word respect that (I'm frankly surprised that Firefox on Windows doesn't), so it doesn't go very far to solving the consistency issues that web designers have to deal with today.

But I do think that being able to articulate the goals will go a long way towards eventually converging on something useful. To date, vertical metrics have generally been pretty hazy and mysterious (notwithstanding John Hudson's great tutorial and the Typekit blogs on the subject), and tool support for getting it right is also poor - especially FontForge.

Thanks to everybody for the comments!

vernon adams's picture

Two separate areas here. First is bugs, errors, cock-ups, e.g. clipping caused by badly set v metrics. ahem :)

Second is the inconsistencies that exist in amongst the standards.
Re Verdana, Arial etc. I did some cross platform, cross browser, tests with a handfull of big name system fonts. They do suffer these issues, because the issue is obviously not necessarily at font level.

I have wondered this myself - is there any solution within font metric standards right now that can be utilised to ease these inconsistencies? (i,e more than Raph states above) or is the core problem at system/browser level?

Jack B. Nimblest Jr.'s picture

>...above) or is the core problem at system/browser level?

The core problem is human. The janitors failed to consider the ramifications of the confluence of analog fonts into digital format, combined with the confluence of adaptive layout and a disintegrated multi-script environment like the web. Simply said enough?

Syndicate content Syndicate content