What units per em do you tend to use during fontdevelopment?
Piotr Grochowski
Posts: 91
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).
Tagged:
0
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.0 -
20480
-
Since 1000 is the safest, I deviate only if the design demands it (which is rare).
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).Piotr Grochowski said:it might be possible to use 256 units per em.
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).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).0 -
2048 unless there is a good reason to change it.
0 -
I've rarely used anything but 1000.3
-
Slightly related: as you all know, 1000 is the recommended em value for PostScript (Type 1) fonts, and Microsoft's TrueType works optimally with 2048. Now as long as I remember – going back to Windows 3.0 at least –, "Times New Roman" has always been advertised as being metrically compatible to Adobe's original Times Roman. Imagine my surprise when only fairly recently I discovered that due to the em differences, this is not 100% true! I was working on a custom PDF engine and was using the metrics from Adobe (it only needs a simple afm parser) but my measurements were off by a tiny degree! I could verify this by recalculation new integer values for 2048/1000 and rounding, and only then the metrics agreed with the physical font. So much for that decades old story "you can use either font, it doesn't matter". I guess the same goes for the other 'compatible' fonts as well.10
-
Microsoft's TrueType works optimally with 2048With 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.
2 -
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.John Hudson said:Microsoft's TrueType works optimally with 2048With 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.
0 -
Does somebody have problems in XPress with OTF fonts of more than 1000 UPM ?0
-
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.4
-
There are curves you just can't make at 1,000 UPM8
-
Yes, but tweaking them might generally be a lesser compromise than deviating from 1000.Chris Lozos said:There are curves you just can't make at 1,000 UPM0 -
PostScript curves or TrueType curves?Chris Lozos said:There are curves you just can't make at 1,000 UPM
0 -
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.
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 TwardochJames Puckett said: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.1 -
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.Adam Jagosz said: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.
2 -
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.James Puckett said: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.
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.1 -
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.
0 -
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."0
-
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.ivan louette said:Does somebody have problems in XPress with OTF fonts of more than 1000 UPM ?
What font, which QXP version?0 -
PostScript curves or TrueType curves?Both, it is an issue of units for handles to snap to without a kink or a bulge.1
-
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.
0 -
@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.0
-
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.ivan louette said:Any of my own fonts created with FontForge at more than 1000 UPM. ...
Feel free to PM to take this offline if desired.0 -
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.1 -
I used 2000 many years ago as it was helpful with very fine outlines such as hairline weights, and I was always exploring that end of the weight spectrum. Then I became concerned about optimization or the standardization of 1000 and decided to revert for good.
At 1000 UPM drawing hairline outlines of 4/5 or 5/6 stem units isn't very problematic, but merging some outlines is challenging. I've had countless battles attempting to optimize point placement especially with intersecting slanted stems, let alone slanted stems intersecting curved stems. At the same time, being stubborn, and not wanting to compromise from my initial drawings, the grid forces compromise to varying degrees. In those cases I just weigh the iterations I make and pick the one closest to the original unmerged outlines.
There is an irony in sticking with 1000 UPM and obsessing over such nuance and details that will ultimately be overlooked by the end user or largely supressed by the rasterizer. When dealing with hairline values, a one unit node shift snapped to the underlying grid is enough to significantly distort a stem or apex etc. At times it's been enough to steer myself away from working on hairline weights altogether, or at least monolinear ones, but for now I'm still sticking with 1000 UPM.5 -
@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).
4 -
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 thereHrant H. Papazian said:@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).
0 -
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.1 -
@""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).
4 -
@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...2
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