Units per em



  • Mark SimonsonMark Simonson Posts: 836
    edited March 27
    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.
  • AbrahamLeeAbrahamLee Posts: 111
    Perhaps tangential, but very educational.
  • 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.

  • Kent LewKent Lew Posts: 649
    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.
  • Kent LewKent Lew Posts: 649
    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.
  • Simon CozensSimon Cozens Posts: 251
    I'm interested in this question too. Is it a problem to have:

      <hhea>    <tableVersion value="0x00010000"/>    <ascent value="1100"/>    <descent value="-288"/>    <lineGap value="0"/>
         ...  </hhea> <OS_2> ... <sTypoAscender value="1100"/> <sTypoDescender value="-288"/> <sTypoLineGap value="0"/> <usWinAscent value="1100"/> <usWinDescent value="288"/> ... </OS_2>

    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.)
  • 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.

  • Kent LewKent Lew Posts: 649
    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.
  • Christian ThalmannChristian Thalmann Posts: 962
    edited July 27
    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:

  • Kent LewKent Lew Posts: 649
    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?
  • Christian ThalmannChristian Thalmann Posts: 962
    edited July 27
    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.


    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.

  • Kent LewKent Lew Posts: 649
    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.
  • 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.
  • Adam TwardochAdam Twardoch Posts: 317
    Also see 

    Note: the UPM=16 test font that I link in that thread is no longer there but I'll upload it somewhere. 
  • Note: the UPM=16 test font that I link in that thread is no longer there but I'll upload it somewhere.
    Github? :)
Sign In or Register to comment.