Units per em
Comments
-
Coarse unit systems like 4upm that I've heard of are mainly proportional typewriters and low-end phototypesetting machines.
I worked with one like that in one of my first jobs, a Compugraphic ExecuWriter. There were only four character widths, and all the fonts were designed around the same set of widths. Depending on the design of the font (whether it was wide or narrow or somewhere between), you would swap out various gears to effectively scale the widths up or down. You made similar adjustments for setting different sizes. It was a pretty crude system but worked well enough for our purposes (weekly newspaper) and fit on a desktop. 18-character LED display, and no longterm memory, so when you hit return it set the line. You could load two fonts at a time, usually regular and bold or regular and italic of the same face.0 -
Even foundry faces appear to have been designed to a unit of 1/4 of a point by some foundries; which makes sense, as without some commonality, how could lines be justified exactly?
Linotype matrices were specified to .001" increments (with machining tolerances of half that) — which is much finer than a quarter of a point, and effectively no unitization at all.
Unlike the Monotype system, which utilized a mechanical calculator for line justification and thus relied upon a unitization of advance widths, the Linotype used a spaceband that consisted of paired wedges that expanded to justify a line and which thus provided continuous adjustment within its min/max range. No unitization or commonality required.
Here’s an image from Wikipedia Commons.
But this is all tangential to Abraham’s original question of units per em for designing digital type.
6 -
Perhaps tangential, but very educational.0
-
Sorry if this is not quite on topic, but how important is it that ascender height and descender depth add up exactly to the UPM number? I seem to remember that that was important for Google Fonts, but I've just heard the contrary statement on typografie.info that the two metrics merely have to add up to less than or equal to the UPM number, with the «less than» option resulting in more talus. The author cites a Garamond from Monotype with UPM = 2048 but asc + desc = 1878.
I was just about to rescale and manually readjust all of my Quinoa family to accommodate the strict rule, but I could save myself the trouble if it were not that important.
1 -
Usually the ascender/descender values add up to the UPM. But that doesn’t mean that the ascenders and descenders of the design need to extend exactly to those bounds.
But which ascender/descender values are you specifically referring to? There are various schemes for setting the hhea Ascender/Descender, OS2 TypoAscender/Descender, and OS2 WinAscent/Descent values in the font info tables, which may or may not add up to UPM exactly.
Not sure you need to be rescaling Quinoa just to adjust the length of your ascenders/descenders.
0 -
P.S. Especially for a rather modest reduction, like I believe you’re considering.
It might be different if ascenders/descenders were being lengthened considerably and would then extend beyond the existing info values — mostly with regard to clipping or solid-set lines crashing.
0 -
I'm interested in this question too. Is it a problem to have:
<div> <hhea></div><div> <tableVersion value="0x00010000"/></div><div> <ascent value="1100"/></div><div> <descent value="-288"/></div><div> <lineGap value="0"/><br> ...</div><div> </hhea> <OS_2> ... <sTypoAscender value="1100"/> <sTypoDescender value="-288"/> <sTypoLineGap value="0"/> <usWinAscent value="1100"/> <usWinDescent value="288"/> ... </OS_2></div>
And if so, what should I do about it? (And also if so, shame on Glyphs for letting me do it without telling me it's a problem.)0 -
I tried to apply the «Webfont strategy» from the Glyphs tutorial on vertical metrics to Quinoa. Does this look right? I'm confused about the fact that the hheaDescender is shorter than the actual descenders.
0 -
I assume that the winAscent = 975 is because you have Vietnamese glyphs, or some other extreme glyphs, that require lots of head room to prevent clipping.
But because this is disproportionate — i.e., not matched by similar extra “leg” room — I don’t know that you should divide your UPM by those 975/235 proportions to get your hhea and typo values.
Instead, I would be more inclined to apportion the UPM in proportion to your actual ascender/descender values — e.g., 754/246 + 210 linegap, or something along those lines.
Others may recommend differently.
Those values you have are probably going to make a setting look baseline-shifted downward in some environments.
1 -
I've decided to use Å, rather than the Vietnamese stuff, for this calculation. While this yields more sensible proportions, there's still some clipping. Now I've set the LineGap to 0 and distributed the 145 units that were set free onto Ascender and Descender according to their proportions (4:1). That seems to work fine, and at least in Word, there's no undue vertical shift:
New values:
0 -
Hmm. Now that looks unorthodox. In that scheme, I don’t see any reason to have hheaAsc/Desc values differ from winAsc/Desc values.
And I believe you definitely want absolute values of typoAsc/Desc to sum to the UPM, with extra line advance put into typoLineGap.
Are you familiar with Karsten Luecke’s paper on Font Metrics?
0 -
From the Glyphs tutorial:If the calculations lead to large line gap values (anything larger than a fifth of the UPM), consider reducing the line gaps and increasing the hhea and typo ascenders by the same value. This may lead to a situation where the typo metrics do not add up to the UPM anymore, but experience shows that fonts work well when this dogma (see further reading below) is broken. Do not forget to do extensive testing.
And:In recent discussions, the ‘UPM dogma’ (the spec requirement that typoAscender and typoDescender add up to the UPM) has been under fire, especially for complex non-Latin scripts. One of the proponents of letting go of the UPM dogma is Victor Gaultney from SIL, who wrote both Best Practice: Design Metrics and Best Practice: Line Metrics.Admittedly, I haven't done extensive testing yet. At least it looks good in Word on my Mac...
EDIT: I just realize my win values are really close to the hhea and typo values. I suppose I could just make them equal.
0 -
Very well. I have not kept up with those latest discussions.
But if you’re going to reduce lineGap to 0 and redistribute the advance into the asc/desc fields, then it seems to me you might as well make them equal with the win values, since they are so close in this case.
2 -
Christian Thalmann said:From the Glyphs tutorial:
...In recent discussions, the ‘UPM dogma’ (the spec requirement that typoAscender and typoDescender add up to the UPM) ...
There is no OpenType spec requirement that typoAscender and typoDescender add up to UPM. There is only a recommendation.
0 -
Also see
http://typedrawers.com/discussion/1075/printing-very-wide-glyphs-in-indesign
Note: the UPM=16 test font that I link in that thread is no longer there but I'll upload it somewhere.0 -
-
Peter Constable said:Christian Thalmann said:From the Glyphs tutorial:
...In recent discussions, the ‘UPM dogma’ (the spec requirement that typoAscender and typoDescender add up to the UPM) ...
There is no OpenType spec requirement that typoAscender and typoDescender add up to UPM. There is only a recommendation.
So why was this a recommendation in the first place? What is the downside of the typoAscender and typoDescender adding up to a value larger or smaller than the UPM?0 -
You may experience "cropped" glyphs.Josh_Finklea said:Peter Constable said:Christian Thalmann said:From the Glyphs tutorial:
...In recent discussions, the ‘UPM dogma’ (the spec requirement that typoAscender and typoDescender add up to the UPM) ...
There is no OpenType spec requirement that typoAscender and typoDescender add up to UPM. There is only a recommendation.
So why was this a recommendation in the first place? What is the downside of the typoAscender and typoDescender adding up to a value larger or smaller than the UPM?
tA + tD = 125% of the UPM is in the safe zone
1 -
You may experience "cropped" glyphs.
tA + tD = 125% of the UPM is in the safe zoneI guess my question really was, does the UPM truly play into the vertical metrics calculations?Lets say we go by Karsten Lücke's guid for vertical metrics, but have the typoAscender and typoDescender add up to a value higher than the UPM (1000).typoAscender 800typoDescender 300winAscender 1000winDescender -400So to calculate the TypoLineGap, we would use... ( OS /2.usWinAscent + |OS /2.usWinDescent| ) - ( OS /2.sTypoAscender + |OS /2.sTypoDescender| )meaning (1000 + 400) - (800 + 300) = 300The TypoLineGap would be 300.In this scenario, is there really anything wrong? The typoAscender and typoDescender add up to 1100, but that value is used to determine the TypoLineGap of 300. We can also assume that if the UPM is 1000, and the vertical glyph metrics are a bit larger like in this example font, then a slightly larger calculated TypoLineGap of 300 could potentially be more fitting than the usual 120% UPM value.Thoughts?0 -
Typo ascender/descender do not crop. If you exceed the 125%, you might get collisions with the preceding or following lines.1
-
There are two separate things here:
1. Relationship of actual letter heights to the scaled body height. The reason for having (in a Latin script font) the actual ascender height plus descender depth be close to the UPM value of the font is to achieve fairly similar scaling of types at the same nominal point size, and hence within the typical contexts of typographic layout. Yes, it was possible to 'cast small on the body' even in metal type, and in digital type it is easy to make letters extend beyond the body height, but as soon as you start doing this you have to also start making adjustments in text size and linespacing values when switching otherwise similar fonts in apps.
2. Management of different vertical metrics settings in OS/2 and hhea tables. If your typoAscender and typeDescender values are close to the actual ascender height and descender depth, and the latter are as described in (1), then rounding them such that they sum to the body height means that you can more easily manage the linespacing value in the typoLinegap independently from the body. Put another way: it allows you to think of the typoLinegap as leading, i.e. as something added to the body height. If you don't do it this way, then you're dividing the leading between the different vertical metrics. That's not technically wrong, but it isn't tidy.
There are circumstances in which both (1) and (2) might be reasonably abandoned. There are also circumstances in which, after all the vertical metrics are set, the UPM value of the font gets changed. These things happen.3 -
Is there a graphic anywhere that shows the relation for all these metrics for a standard font design? Each time I feel like I understand what’s going on, but hear one of you who I’m confident really does understand describe them, I get more confused. Thanks.0
-
John Hudson said:There are two separate things here:
1. Relationship of actual letter heights to the scaled body height. The reason for having (in a Latin script font) the actual ascender height plus descender depth be close to the UPM value of the font is to achieve fairly similar scaling of types at the same nominal point size, and hence within the typical contexts of typographic layout. Yes, it was possible to 'cast small on the body' even in metal type, and in digital type it is easy to make letters extend beyond the body height, but as soon as you start doing this you have to also start making adjustments in text size and linespacing values when switching otherwise similar fonts in apps.
2. Management of different vertical metrics settings in OS/2 and hhea tables. If your typoAscender and typeDescender values are close to the actual ascender height and descender depth, and the latter are as described in (1), then rounding them such that they sum to the body height means that you can more easily manage the linespacing value in the typoLinegap independently from the body. Put another way: it allows you to think of the typoLinegap as leading, i.e. as something added to the body height. If you don't do it this way, then you're dividing the leading between the different vertical metrics. That's not technically wrong, but it isn't tidy.
There are circumstances in which both (1) and (2) might be reasonably abandoned. There are also circumstances in which, after all the vertical metrics are set, the UPM value of the font gets changed. These things happen.So regardless of general standards of type height to point size relationship as mentioned in #1, does it make more sense to keep the UPM at 1000 and have the typoAscender and typeDescender values add up to bit more than 1000, say 1100, or does it make more sense to change the UPM to a "nonstandard" value of 1100 and have the typoAscender and typeDescender match that value (without scaling)?0 -
All things being the same, if you change your UPM from 1000 to 1100, your font will display smaller at a given font size. The font's EM is scaled to the font size.4
-
I understand that if the UPM is changed from 1000 to 1100, then the font will just display smaller, but my question is basically >>>Mark Simonson said:All things being the same, if you change your UPM from 1000 to 1100, your font will display smaller at a given font size. The font's EM is scaled to the font size.
Are there any technical/application issues with having either...
A. a non-standard UPM (like 1100).
or
B. having the typoAscender and typoDescender add up to a larger value than the UPM.0 -
Yes, some old software will still botch things up because it assumes 1000.Josh_Finklea said:Are there any technical/application issues with having either...
A. a non-standard UPM (like 1100).0 -
I seem to recall that 'old software' included macOS X and some PDF generation software. Been a long time since I came across that myself, though.Hrant H. Papazian said:
Yes, some old software will still botch things up because it assumes 1000.Josh_Finklea said:Are there any technical/application issues with having either...
A. a non-standard UPM (like 1100).1 -
For TrueType-flavored fonts you can safely specify any UPM between 16 and 16384, and the only place you need to do it is the head table.
For CFF-flavored fonts, it's more complicated: in addition to the head.unitsPerEm field, you need to change the /FontMatrix parameter inside the CFF table. The problem is that various PS/PDF creation apps as well as readers often ignore or misinterpret the /FontMatrix parameter. Some always assume it's [0.001 0 0 0.001 0 0] (which is the correct setting for UPM=1000 bit is not for other UPM sizes).
Unfortunately, when some environments correct these problems, new environments introduce this problem anew, see e.g. https://github.com/nodebox/opentype.js/issues/115
So basically, non-1000 OTFs are always broken "somewhere". One possible reason for it is that the https://www.microsoft.com/typography/otspec/head.htmdoes not in any way mention CFF.FontMatrix, and the specification for CFF is, well, really weird. It's written from the perspective of CFF being a standalone font asset living inside a PDF, rather than a table inside an OpenType font. So many software developers fail to see the link — they try to implement in good faith what's in the spec, but in reality, handling fonts requires much more knowledge that is largely undocumented.2 -
"Old software" also includes new software like opentype.js. Actually right now we have a problem — for decades, there were only about 4-5 font rendering engines (well, Adobe itself had several but I'm simplifying them as one), and the engineers working on those in the major companies knew each other personally (often having worked at some common company in the past).Dave Crossland said:
I seem to recall that 'old software' included macOS X and some PDF generation software. Been a long time since I came across that myself, though.Hrant H. Papazian said:
Yes, some old software will still botch things up because it assumes 1000.Josh_Finklea said:Are there any technical/application issues with having either...
A. a non-standard UPM (like 1100).
But right now, we have dozens of new implementations in various programming languages, for the web, for gaming, for all sorts of server-side document creation, many with by a young generation of engineers. Pretty much all of those implementations are more or less half-baked and buggy, or they may implement the spec but fail on real-life fonts that carry tons of app-specific quirks in them.1 -
This makes clear what the problem is.Adam Twardoch said:One possible reason for it is that the https://www.microsoft.com/typography/otspec/head.htmdoes not in any way mention CFF.FontMatrix, and the specification for CFF is, well, really weird. It's written from the perspective of CFF being a standalone font asset living inside a PDF, rather than a table inside an OpenType font. So many software developers fail to see the link — they try to implement in good faith what's in the spec, but in reality, handling fonts requires much more knowledge that is largely undocumented.
It's as if implementors and font designers are not reading the same spec. And, indeed, in many cases they aren't, as you've just made clear. A designer creates, say, a True Type font. It gets embedded in an OpenType font or converted to an OpenType font or however you want to put it... and then a WOFF font to go on a wep page, or to something else in order to be embedded in a PDF document.
Perhaps by design, some of these formats aren't intended to support all the features of the source formats. More insidiously, though, while there is no intentional incompatibility, when one is rewriting documentation and avoiding plagiarism in doing so, of course errors will creep in.
No doubt there will soon be a book from O'Reilly, say, that will give font renderer programmers guidance on avoiding this mess, or perhaps one already exists - one that explains why it's needed to look at other specs besides the one for the format one is actually implementing to know what's really going on.
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 799 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports