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).
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.
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).
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).
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.
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.
What font, which QXP version?
Feel free to PM to take this offline if desired.
AFAIK 2000 UPM is Google Fonts standard for variable fonts.
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.
— 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.
I actually got FL7 recently but have yet to make a real effort to migrate to it... It's so different...