What units per em do you tend to use during fontdevelopment?

Piotr GrochowskiPiotr Grochowski Posts: 91
edited September 2020 in Technique and Theory
The em is the base metric, but is not based on any specific horizontal or vertical font feature (and neither is it the font height, which is WinAscent+WinDescent), but rather the em is for scale. For instance in 16ppem the em size is 16 pixels. The units per em determines how many units the em is, and it affects the process of fontdevelopment. What em size do you tend to use? Among TrueType font designers it is common to use 2048 units per em and among PostScript font designers it is common to use 1000 units per em, however it is possible to use any units per em in fontdevelopment. For instance, it might be possible to use 256 units per em. In fake bitmap fonts the em size will likely be a multiple of the bitmap em size in pixels (not necessarily the bitmap font height).
«1

Comments

  • Usually, I use the same UPM during development, that I intend to have in the final font.

    Aside from that, I am not especially committed to any particular UPM.

    A current project has a 480-unit UPM scale, which I find a bit constraining. If I had it to do over again, I would have at least doubled it.
  • Chris LozosChris Lozos Posts: 1,458
    2048

  • Since 1000 is the safest, I deviate only if the design demands it (which is rare).
    it might be possible to use 256 units per em.
    In fact I remember David Berlow once saying that such a small Em is useful for Chinese fonts, because it ends up making a big difference in the size of the font (in bytes).
    In fake bitmap fonts the em size will likely be a multiple of the bitmap em size in pixels (not necessarily the bitmap font height).
    Yes, and since many bitmap fonts rely on a nominal size of 8pt, the pixel size becomes 1000 / 8 = 125 (which is what I've used myself, like in Mana).
  • 2048 unless there is a good reason to change it.
  • I've rarely used anything but 1000.
  • John HudsonJohn Hudson Posts: 2,955
    Microsoft's TrueType works optimally with 2048
    With any power-of-2 value. The performance benefit is pretty minimal these days, and Microsoft have allowed/requested us to use non-power-of-2 UPM values on a couple of projects in the past few years, although it remains their recommendation.
  • Piotr GrochowskiPiotr Grochowski Posts: 91
    edited October 2020
    Microsoft's TrueType works optimally with 2048
    With any power-of-2 value. The performance benefit is pretty minimal these days, and Microsoft have allowed/requested us to use non-power-of-2 UPM values on a couple of projects in the past few years, although it remains their recommendation.
    Any value from 16 to 16384 is valid, but for it to be eligible for Visual TrueType it must be any value from 64 to 16384. Presumably some of the high level functions weren't designed to function with units larger than 0.015625 em.
  • Does somebody have problems in XPress with OTF fonts of more than 1000 UPM ?
  • I stick with 1000. I’ve tried finer grids but I get annoyed with having to push the buttons too many times to move nodes around.
  • There are curves you just can't make at 1,000 UPM
    Yes, but tweaking them might generally be a lesser compromise than deviating from 1000.
  • There are curves you just can't make at 1,000 UPM

    PostScript curves or TrueType curves?
  • Adam JagoszAdam Jagosz Posts: 689
    edited October 2020
    At 1000 you can't always get consistent very thin diagonals (5/1000 units) etc. And of course optical correction (horizontal vs. vertical width) is out of the question as a 4-unit vertical becomes too thin to go with 5-unit horizontals in a monolinear design.
    I stick with 1000. I’ve tried finer grids but I get annoyed with having to push the buttons too many times to move nodes around.
    You can change the Shift+arrow key step in app settings (at least in FontLab). Now that I think of it though, it might be more useful to have it as a per-project setting, right? @Adam Twardoch
  • At 1000 you can't always get consistent very thin diagonals (5/1000 units) etc. And of course optical correction (horizontal vs. vertical width) is out of the question as a 4-unit vertical becomes too thin to go with 5-unit horizontals in a monolinear design.
    Indeed 1000 units per em is not suitable for every single font out there, and using more units per em (therefore, a smaller unit size than 0.001 em) would result in more precision necessary for the fontdevelopment of hairline and such fonts.
  • Craig EliasonCraig Eliason Posts: 1,397
    edited October 2020
    I stick with 1000. I’ve tried finer grids but I get annoyed with having to push the buttons too many times to move nodes around.
    The intricacy or fineness of contours can certainly call for higher resolution as has been said, but I like that James is also bringing up production efficiency. 

    Choosing where to put a node between x = 723, 724, or 725 versus choosing between x = 1446, 1447, 1448, 1449, or 1450 may seem like a tiny amount of time to be concerned with, but that delta for every x, and every y, of every node, of every glyph, of every master certainly adds up. And if x=724/1000 and x=1447/2048 prove indistinguishable in use, that incremental time was wasted.
  • Choosing where to put a node between x = 723, 724, or 725 versus choosing between x = 1446, 1447, 1448, 1449, or 1450 may seem like a tiny amount of time to be concerned with, but that delta for every x, and every y, of every node, of every glyph, of every master certainly adds up. And if x=724/1000 and x=1447/2048 prove indistinguishable in use, that incremental time was wasted.
    724/1000 = 0.724 em
    1447/2048 = 0.70654296875 em

    I don't think 2048 is really two times 1000 unless you're making the 2048 master a bit smaller for whatever reason. 724÷1000×2048 is 1482.752, not really 1446, 1447, 1448, 1449, or 1450.
  • Craig EliasonCraig Eliason Posts: 1,397
    edited October 2020
    Okay, I changed the premise of the analogy from 2000 to 2048 while writing that. But I would hope my point was clear. Pretend I wrote "1480, 1481, 1482, 1483, or 1484" and "1481/2048."
  • Does somebody have problems in XPress with OTF fonts of more than 1000 UPM ?
    No...at least not that I am aware of. I only have a few otf fonts that use 2048 upm to test, though. They work fine.

    What font, which QXP version?
  • Chris LozosChris Lozos Posts: 1,458
    PostScript curves or TrueType curves?

    Both, it is an issue of units for handles to snap to without a kink or a bulge.

  • Chris LozosChris Lozos Posts: 1,458
    It is more about what tool do you use for what job. A six foot chainsaw to cut a tree or a micro laser for brain surgery.
  • @Mike Wenzloff Any of my own fonts created with FontForge at more than 1000 UPM. They display fine on screen in XPress but after conversion to PDF the higher level of UPM I use and the more every character decreases in size while apparently remaining at the good location. Quoted by my friends who use XPress (I will ask for the versions). I personnally use Scribus and there no problem.
  • Any of my own fonts created with FontForge at more than 1000 UPM. ...
    Hmm. I'm not using FF for my fonts. If there is an issue that I'm overlooking, though, it would be good for me or your friends to file a big report. Can you either share or point me to such a font for purchase that demonstrates the issue? I can only go back from the current version to version 9 for bug verification. But if there is an issue in the current version I can send the problem to the appropriate person at Quark.

    Feel free to PM to take this offline if desired.
  • I started with 1000 UPM for low contrast/rounded endings font. Sometimes it's very hard to define rounded corners of the thin master in 1000 UPM, so I changed it to 2000 UPM. 

    AFAIK 2000 UPM is Google Fonts standard for variable fonts.
  • @Michael Jarboe One thing that helps a lot with slanted forms is using slopes that are a ratio of integers, instead of degrees (which make no sense on a Cartesian grid).

  • Igor PetrovicIgor Petrovic Posts: 262
    edited November 2020
    @Michael Jarboe One thing that helps a lot with slanted forms is using slopes that are a ratio of integers, instead of degrees (which make no sense on a Cartesian grid).
    Interesting. How this affects the workflow? Do you first slant the upright by some degree and then adjust nodes to the ratio of integers, or something else...How do you get there :)
  • You can build things from scratch, or if you slant upright forms there's something you have to be careful of: the slanting degree only goes down to two decimal places (at least in FontLab5) so too far from the origin and you'll get rounding errors.

    BTW:
    — Converting an integer slope to a degree is a simple arctangent function.
    — I once asked FontLab to support integer-ratio slopes but I don't know whether it's in FL7.
  • John HudsonJohn Hudson Posts: 2,955
    @""Hrant H. Papazian"
    I once asked FontLab to support integer-ratio slopes but I don't know whether it's in FL7.
    It is implemented in the FL7 font info. If you input the italic slant angle, it will automatically fill the nearest run over rise integer ratio. If you input the integer ratio values, it will automatically fill in the italic slant angle rounded to two decimal places (which I think is a limitation of the font file format).

  • @John Hudson Wow, good news! Thanks.

    I actually got FL7 recently but have yet to make a real effort to migrate to it... It's so different...
Sign In or Register to comment.