View Single Post
Old 07-19-2011, 01:30 AM   #13
charleski
Wizard
charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.charleski ought to be getting tired of karma fortunes by now.
 
Posts: 1,196
Karma: 1281258
Join Date: Sep 2009
Device: PRS-505
It seems this isn't restricted to specialist fonts either, see http://typophile.com/node/19130.

After doing a bit of digging, it seems the real problem is the lack of standards in this area. The best guide I could find for the best practices is this article, which makes it clear that none of the specifications make any requirement about vertical height: "In fonts with very large ascenders or descenders, the default line distance will be accordingly large. This should be acceptable - designers will set leading manually anyway." So in other words, the specs assume that the font will be set manually, with someone adjusting the leading to suit.

The only spec that provides any guidance on vertical font size for applications in which the leading will not be adjusted manually is provided by Microsoft.

On taking a closer look at the properties of Minion, which like all the Adobe fonts I've used is well-behaved and doesn't spring any surprises, it turns out that it follows the MS spec exactly: OS/2.sTypoAscender = 727, OS/2.sTypoDescender = -273 and OS/2.sTypoAscender - OS/2.sTypoDescender = 1000 = specified UPM with OS/2.sTypoLineGap set to 200 (1.2 x UPM). Lexicon, on the other hand, has a UPM of 1000, but OS/2.sTypoLineGap = 76 (!) and OS/2.sTypoAscender (814) - OS/2.sTypoDescender (-307) = 1121. So the line collision is baked into the font itself.
charleski is offline   Reply With Quote