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

Great work, Raph.

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

Jason C

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)

Hi Raph:
Great work!

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

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.

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.

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.

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.

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!

@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!

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?

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