Can you create .otf fonts with a upm greater than 1000? I've been told that generating an .otf font automatically downsamples to 1000upm, even if you built the font on a finer grid. But FontFont's promotional material suggests that their FF DIN Round was created at a higher resolution—I don't think they specify how much higher—and they're selling the typeface in .otf format. Can't find this info in the MS OTF spec, or anywhere else...
0
Comments
This stuff is pretty well documented in some old Typophile threads, but you know how that goes
Yes, there might be software that would not use the actual UPM value and just assume that its 1000 for CFF fonts, but that's a bug that these software makers need to fix. The more CFF fonts with arbitrary UPM values we have, the more the software makers are forced to built their software properly.
I do lettering and logotype projects in font editors and have run into problems with large UPMs in Fontlab. Fontlab appears to have a y2k-related bug where it can't do math with five significant figures. a 9,999 upm wide glyph is fine, but anything larger explodes. I've pushed robofont up to 60,000 upm with no real problem (zooming can get weird).
@Ralf: What UPM have you been using for new CFF fonts, if you don't mind my asking? Have you gotten any complaints from users, or seen any issues with InDesign or any other common software?
@Jackson: 60,000 upm? Yikes. There's something Fantastic Voyage about that. All I need, most likely is 2000 to 4000. Hopefully that won't mess up the cursors & such too much.
I had a user reporting, that PDFs created in XeLaTeX and viewed in Adobe Reader were totally messed up concerning the type size. But all common and recent design and text apps seem to work fine with arbitrary UPM values.
Why 2048 rather than 2000? Is there some advantage conferred by the extra 48 units, or by the exact match w/ TTF standard?
Anyone else regularly using non-standard UPMs for OTF/CFF fonts? Is there anyone who's been using them to make webfonts?
I remember one other bug related to odd upms:
I released my script font Lakeside with a UPM of 1307, but the spacing came out wrong in QuarkXPress (too tight), which of course is a disaster for a connecting script. Luckily, I found out about it right away, and was able to release a new version before many people had purchased it. The final upm was 2000, which Quark was able to set properly. (No other programs that I know of had any trouble with 1307.)
Incidentally, upscaling was the only practical option in this case. Scaling down to 1000 caused all sorts of rounding problems with alignment and small curves. There are probably some distortions introduced in going from 1307 to 2000, but they are not noticeable.
When you do manipulations with contours in a glyph editor where positional values are integers, (cumulative) rounding errors might appear. Given such a glyph editor, the best way to limit such rounding errors (or to limit the relevance of such errors), is by working in the highest practically possible UPM resolution. For this reason, I decided to do a part of my glyph editing work in a 10000 UPM resolution. (I decided about this in 2007. In the future, I expect that all glyph editors will support fractional positioning values, so then this reason to choose to work in a 10000 UPM resolution might not be valid anymore.)
When you work in a glyph editor where positional values are integers, reducing the UPM will result in rounding errors. In http://typophile.com/node/30913, Tim Ahrens (28 Jan 2007 — 5:07pm) rightly writes that, when scaling down the UPM, you get the smallest rounding errors when you scale down to 33%. When scaling down 10000 UPM to 33%, an UPM of 3333 results. So, because I do part of the contour manipulating work in 10000 UPM to minimize rounding errors, and because I want minimal rounding errors when reducing this UPM to a value which can be used in a finished font, the "magic" UPM value of 3333 results. All my current fonts are .otf (OT/CFF) fonts with an UPM of 3333.
The choice for the exact UPM value of 3333, is based on reasons which are in the realm of font production. In finished fonts, it doesn't matter very much whether the UPM is 3200, 3300, 3333, 3400, or 3500. However, a bigger UPM in finished fonts, makes smaller details possible in glyphs, which is an advantage. With a higher UPM, glyphs can be designed more precise. This advantage is not really relevant when fonts are being used in small texts and webfonts, because then the small details will not be visible. When fonts are being used in bigger display sizes, these details will be visible, so then the glyphs will be displayed more precise. So the reason for choosing a higher UPM than 1000, is to be able to design more precise glyphs. And of course, telling potential customers about a higher than average UPM, is (yawn) marketing.
Is it really true, that .otf fonts with an UPM up to 4000, can be used now in all major applications? I am afraid not. Recently, problems showed up for me with .otf fonts with an UPM of 3333. This bad news reached me a week ago, and I am still in the phase of absorbing it. The culprit of the bad news is Microsoft Word 2011 for Mac. A week ago, Adam Twardoch reported to me that Word 2011 for Mac does not support .otf fonts with an UPM of 3333. (Word 2011 for Mac does support .ttf fonts with an UPM of 3333. I don't know whether Word 2011 for Mac supports .otf fonts with an UPM of 2048.)
Adam also reported that Microsoft Word 2011 for Mac does not support style-linking between different weights, if the two fonts involved are not the Regular (400) and the Bold (700) font. So, for instance, a style link between a Light and a SemiBold font, is not supported by Word 2011 for Mac. I don't know what happens when a font family with such a style link is being used with Word 2011 for Mac. (See http://typophile.com/node/95677.)
The font problems in Word 2011 for Mac are so big, that I feel that it should not be up to font designers to create a workaround for them. I think that Microsoft should correct these problems in Word 2011 for Mac. (There are good reasons for font standards. Both font designers and software developers should adhere to these standards.)
I am going to email Microsoft, and ask them if they know that Word 2011 for Mac has these font problems, and if they intend to correct these problems in an update. In the meantime, I will create a 3333 UPM .ttf-version of fonts that customers want to use in Word 2011 for Mac. I don't know yet what I will do for the long run, with respect to the font problems in Word 2011 for Mac.
The other vertical metrics (TypoAscender/Descender, WinAscent/Desent, hhea Ascender/Descender and Line Gaps) also play and important role in making the glyphs look bigger or smaller, and they also affect the default line-height.
I would never change the UPM to make glyphs look bigger or smaller. Changing the UPM is, I would say, meant for changing the resolution of a font, not the size. When changing the UPM to change the resolution, of course, all metrics values which are relative to the UPM, should be changed too. To make glyphs look bigger or smaller, I would use scaling. (After scaling, it is obvious that all relevant metrics have to be changed too.)
I was pointing to the importance of the "other metrics", that nobody mentioned to the moment.
For example, for the same font and the same UPM, you can make your font to render bigger or smaller by changing the "other metrics" only (And, of course, the same effect can be achieved by modifying the UPM.)
The thing is, that if you optimize both, the UPM and the "other metrics" you can get your font to render bigger, witch is very important for web fonts.
That's the reason why some fonts looks so small and other so big on the web, and is not only the x-height or the UPM that produce those differences. The "other metrics" play an important role, maybe the one that makes the biggest difference. So they mast not be overlooked when discussing the UPM, because they are closely related.
I haven't run into any issues yet. Should I post a sample font?
When a font is rendered on a device, the UPM is scaled to the type size and all other values follow suit. Changing the UPM changes that scaling factor. It's as simple as that.