Saw this on twitter today and thought I would ask about it on here because I've never got a clear answer:
Type designers: How do you decide the size of your type on the "body"? Do you just use the full 1000 upm, ascender to descender? -Dave Foster (@ fostertype)
Making sure that the whole letter (including accents) is in the 2048/1000 upm space can be ideal because designers are often building templates where the type has to fit in that space. Having parts of the typeface get cut off could be problematic.
I feel the only exception could be swashes that go beyond the ascenders and descenders. In those instances, I have done what Karsten Lücke suggests: http://kltf.de/downloads/FontMetrics-kltf.pdf
Comments
UPM 1000. The lowest accent, usually ogonek or comma-accent is my lowest point and the top of the Å is my high point. I scale the font so the difference between those points is 1200 or slightly less. My settings are based on the highest and lowest point measurements. hhea Ascender=highest point. hhea Descender=lowest point. linegap=0. TypoAscender = highest point minus 200. TypoDescender = lowest point. TypoLineGap = 200. WinAscent = highest point. WinDescent = lowest point
This technique may not adhere to specs, but nothing gets cut off and it looks the same across platforms. Maybe not the same but more "the same" than using "proper" settings. I'll go in an finesse the numbers in less conventional designs but that's my general technique.
Vietnamese stacked accents can go past the highest point. When you have wild swashes, or paint drips, you can go past the 1200 limit but you can't expect it to behave perfectly in all applications.
It essentially comes down to one's design, the intended usage of the font(s) and the target environments. Stacking diacritics (precomposed or on-the-fly) and some non-Latin scripts might leave you with crazy vertical dimensions that need more attention. Also, fonts for UI usage almost always need special treatment.
The result was a face that, viewed in type testers, looked 10% smaller than all its competitors. I'm pretty sure this has hurt sales.
When I release the 2.0 version, it'll be 10% bigger on the em. And the cap diacritics will stick up above the full body height, just like everyone else's.
The cutting-off problem is related to WinAscent/WinDescent and hheaAscender/hheaDescender, not necessarily to the relation between UPM and bounding box height as suggested by the Twitter posting.
Any thoughts on proper vertical metrics?
Thanks.
However, for David's example, I would recommend this only for each asc/descender family group, since those families are unlikely to be used together/mixed in single lines; rather, each is intended for use with different line-heights.
I do get the feeling from test viewings, however, that the general web design and reading public's 21-year exposure to default line spacing is going to be as big an impediment to quality reading, as all the other non-defaults we've had to evangelize about real type since before the web. But there's no sense complaining when there's the suspicion of slowed reading somewhere.
Ascender – TypoAscender
Descender – TypoDescender
Line gap – TypoLineGap
Safe Top – WinAscent
Safe Bottom – WinDescent
Leaving some talus ("internal linespacing") is important to avoid collisions of basic things like g/y and f (when set flush) but rare things like cap accents should be allowed to drift above the Em.
Determining the talus comes first; around 5% is a good benchmark (and most of it should be allocated to the top). And flattening the cap accents to make them slightly ungainly (like one has to do even with the "g" anyway) helps reduce potential problems.
The WinAscent ("Safe Top") and WinDescent ("Safe Bottom") values should be the sum of the Ascender and Descender values plus the Line Gap value (i.e. if you have 1490 as the Ascender value, and a 410 Line Gap value, Safe Top will be 1900).
Cross-platform vertical metrics is a hardest things for me now. Three different tables and so many different approaches. It could be clearer in a future and right now it's a challenge
I read this article https://glyphsapp.com/learn/vertical-metrics and at this moment choice Webfont strategy way with including important diacritics to the Ascender. Here what I have:
UPM = 1000
typoAscender = 910 (ÀÅ)
typoDescender = −210 (pĢ)
winAscent = 1080 (ẴẲ)
winDescent = typoDescender
Line gap = 120 (910+210−1000)
It does come from metal type, where it's also called the "beard" but not consistently (plus that terms is a bit overloaded). There it's the slope from the face to the shoulder (which might sound like it should be called the "neck" :-) which typically only reaches the edges of the sort in all-caps fonts, so not the best validation... But in digital it's basically a nice tight term for referring to the combined space above the ascender line and below the descender line, to the edges of the Em. An extremely useful reference in terms of (virtually) eliminating collisions in flush setting versus how large the font appears on the body (although the x-height does do the latter to a greater extent).
It's food for thought and a real dilemma. Now I understand why the accents above the uppercase are smaller than those above lowercase (on some fonts), for save every available vertical unit.
Is there a repository of commonly used typeforms for which no precomposed Unicode codepoints exist and which must be constructed using combining marks instead? Should such a repository even be consulted for vertical metrics, or are those solely based to the precomposed glyphs in the font?