Microsoft's guidelines are the closest thing to a standard I know.

Nice question.

I've generally been following the first model, with caps at around 725 units. Uppercase accents then fit up to about 975 units, and descenders go down to about -225 units. However in my latest creations I'm more tending to scale the letters down so cap height is about 575, cap accents up to 850 and descenders to -165, which avoids crashing as you mentioned. My opinion is that default line spacing should be deliberately designed into the font to look as polished as possible. (No crashing.)

Word space is another one that sometimes seems not to get designed carefully.

Within the em height, I generally leave a little bit of space above and below the extenders, with cap accents beyond that.
Then I add something in (Typo)LineGap.
However, in The Modern Suite I went with an old school "solid" setting as the default, and made (Typo)LineGap zero.

For a very intricate font, with lots of points I made it 10,000 units high and generated it as True Type. Something you can't do I believe in Type 1.

If you just want to ask "what do people do" that can be done without getting technical. But you then bring up "arguments" (your word) for why people should do certain things.

The arguments given are based on understandings or misunderstandings about some of the technical aspects of metrics. So I can't discuss those arguments for or against different kinds of spacing without getting technical and bringing up some of the same things (like what programs/OSes do what line spacing determined how) that are in the thread that you said you didn't want to talk about.

> - with a cap-height of around 700 upm, some parts of the font (accents or even ascenders) will reach out of the em and will be cropped in some programs (on screen).

Going beyond the em does not result in cropping in almost any programs. Both Mac OS and Windows use things other than the em to determine where to clip, as discussed in that other thread.

> - if line spacing is left to auto, it often looks too tight. Sometimes ascenders and descenders even touch. If the letters are drawn smaller into the em, the line spacing looks larger and in most cases better.

In typical Mac and Windows applications (like office type apps), line spacing is determined by things in addition to the size of the letters relative to the em, and you can set those metrics as you wish to get more generous line spacing. In more sophisticated DTP apps, yes, this can be an issue, though of course those users are supposedly more sophisticated and could adjust the spacing.

The technical aspects are discussed in that "other thread."

> - on the other hand, some users might get confused if a font with the same point size all of a sudden looks much smaller.

Agreed.

> - also some fonts with tiny details might have "resolution" problems when drawn too small (e.g. Zapfino with extremely tall ascenders).

For this case, I don't see that a slight variation in size of the letters (in font units) is likely to help. Instead, change the resolution of the em. (e.g. 2000 font units instead of 1000).

I haven't checked this, but I wouldn't be surprised if I learned that when Apple did their famous rescaling of Zapfino for OS X 10.2, they simply changed the size of the em while leaving everything else constant. Zapfino got smaller, but (if my supposition is correct) it would have done so with no loss of detail or change in the outlines. The max units per em (UPM) for TTFs is 16K, so that wouldn't have been a problem.

Cheers,

T

Thanks for your help so far, especially Thomas for clarifying a few things.
I understand, that one needs to get a bit technical to answer my question, I just wanted to avoid to start the same metrics discussion again...
Yes, I'd like to know if there are still some principles in use to choose the size of the letter drawing. And of course, I'd like to now the reasons why or why not people use them (sorry, the word "argument" was probably misleading - "reason" would be better)

> Going beyond the em does not result in cropping in almost any programs. Both Mac OS and Windows use things other than the em to determine where to clip, as discussed in that other thread.

Here is an example:
In Excel (Mac 2008) letters of some fonts are cropped while you're typing (Helvetica System TT). They will be displayed right once you leave the cell, but the accents look like they belong to the upper line. This doesn't happen if you design the font completely within the 1000 upm.

And another one in Word (Mac 2008) with Times (System TT):

I don't think this is marginal. I actually find it quite annoying. But maybe I'm wrong if I always thought that the reasen for this cropping is drawing beyond the em.

More legerdemain with cap diacritics:

1. Create a new document in Apple TextEdit.
2. Select a font.*
3. Enter two returns and then type or paste ÄÖÜÉÈ.
4. Now select the blank line above: the initially missing diacritics magically appear.
5. Delete the accented caps on line 3: the base characters vanish, the dots and accents above remain!

*) This works with a lot of fonts, including Consolas, Corbel, Constantia, but also Adobe Garamond, Auto or Malabar.

Apparently, this is just some line-related redraw bug. As soon as the line above is affected, the bug disappears. Still annoying, indeed.

From the answers I got here and thru the ATypI mailing list, I'd like to propose this model (for latin fonts):

- Draw your letters completely within the em, so that the bounding box of all letters lies within the em. Use global guides to mark your actual (visual) ascenders, x-height etc.
- For your Vertical Metrics you can then use easy values to make line spacing consistant:
make all ascenders (TypoAscender, WinAscent etc.) the same value; same for all descenders; make all line gaps zero.
- If you run into resolution problems, set the upm size to 2048 (or even 10000).

advantages:
- no clipping nowhere and no annoying accent wizardry
- line spacing is consistant (and also looks quite good as it appears slightly bigger)
- the font looks a bit smaller as usually, which makes the default 12pt setting in many programs a much better choice
drawback:
- users have to get used to a smaller appearance of the font when they apply the point size
(which I think is acceptable)

It's a bit like back to hot metal type. Like "Ascender" and "Descender" would be the edges of your lead letter and you can't go beyond.
What do you think?
o.

Once you added diacritic letters e.g. for Vietnamese you may hear complaints that the type looks rather small. :)
The OT list remarks about Excel make me feel like OS/2.TypoAscender = OS/2.WinAscent = hhea.Ascender indeed ... But where does it get us? If foundries try to please even the crappiest application by making one more tweak, this suggests that everything can be solved on the font side – which is a never-ending story since every new application will come up with new peculiarities.

Sounds good in theory, but one point where it will break is when you have to add letters which use stacked diacritics, for example Ǚ (used in Chinese Pinyin) or Ắ (Vietnamese).

I agree with Karsten. It is not the job of a fontmaker to compensate bugs in OSes or applications. The interface between the fontmaker and the application/OS developer is the (OpenType) specification. If a font, which is conformant with the requirements and recommendations of the specification, behaves bad, then the bug is on the application side.

I am opposed to making the os2.sTypo metrics identical to the os2.usWin (windows) and head (Mac) metrics, and will certainly not do so in future fonts I create. Speaking for Extensis corporately, although we will look to get consistency between the Mac and Windows metrics in our WebINK web fonts, we won't expect the Typo metrics to match those.

The whole reason the Typo metrics were invented was to allow for typographically sensitive numbers that were not related to clipping and the "old" platform-specific metrics, so as to actually express accurate values for ascender, descender, etcetera, unrelated to clipping of bitmaps on screen.

Regards,

T