Maximum UPM for .otf fonts?

Max PhillipsMax Phillips Posts: 474
edited August 2012 in Technique and Theory
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...
«13

Comments

  • ttf otfs can be 2048ems . . .
  • James PuckettJames Puckett Posts: 1,969
    edited August 2012
    Theoretically OTF resolution goes up to something like 16,000x16,000. But a lot of software assumes that a 1,000 UPM grid and problems range from the font appearing scaled down in menus to just being unusable. Tiro ran into problems when they released Marian Bantjes’ Restraint with a high UPM, so maybe they can tell you more.

    This stuff is pretty well documented in some old Typophile threads, but you know how that goes :(
  • James PuckettJames Puckett Posts: 1,969
    On a related note, in Glyphs you can set grid stepping to 0 and type in floating-point coordinates for any node. But I suspect some software would freak out over that, two.
  • RalfRalf Posts: 170
    edited August 2012
    I stopped using 1000 units for new CFF fonts. The OT spec allows it, so why should I my limit my work in this way.
    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.
  • The only bug I know of with using non-1000-upm otfs is an aesthetic one where some older versions of CS draw the text cursors and highlights unusually small.

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

  • Well, it looks like I might have misunderstood the guy who said the a upm of 1000 was set in stone in the PostScript spec. Or maybe he misunderstood. He teachs type design and production at a pretty well-known school, so I hope not.

    @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.
  • Mark SimonsonMark Simonson Posts: 1,652
    edited August 2012
    If I recall correctly, it's only PostScript Type 1 fonts that must be 1000 upm. OpenType fonts are not Type 1 fonts, even if they contain PostScript outlines.
  • There was a mention of UltraPrecision™ font technology in another thread recently—that's advertised as fonts have an UPM grid of 3333 by 3333 units. Would anyone please clarify whether there is any inherent advantage to finished fonts that use this magic number, or whether it is (cough) marketing? Sorry, I have a cold, it's the end of winter here.
  • RalfRalf Posts: 170
    Well, it looks like I might have misunderstood the guy who said the a upm of 1000 was set in stone in the PostScript spec.
    But that’s not true for PostScript-flavoured OpenType fonts.
    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?
    A typical choice would be to go for 2048, like in TrueType. Or even double or triple that if you have very complex glyphs.

    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.
  • Max PhillipsMax Phillips Posts: 474
    edited August 2012
    Thanks, Ralf. I think I can risk annoying people who create PDFs in XeLaTeX and view them in Adobe Reader.

    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?
  • Mark SimonsonMark Simonson Posts: 1,652
    edited August 2012
    2048 is a round number in binary, like 1000 is in decimal. It presumably made things more efficient and faster for the 8 to 33mhz processors and 1 or 2MB of RAM that were typical at the time TrueType was introduced. Nowadays, it's just a vestige of an earlier time.

    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.
  • Ben BlomBen Blom Posts: 250
    Would anyone please clarify whether there is any inherent advantage to finished fonts that use this magic number [3333], or whether it is (cough) marketing?
    Concerning the maximum UPM for .otf fonts, see http://typophile.com/node/30727, http://typophile.com/node/32134, and http://typophile.com/node/30913. From this I concluded a long time ago, that .otf fonts with an UPM up to 4000, should be a safe possibility. (In http://typedrawers.com/discussion/comment/863/#Comment_863, George confirms this conclusion.)

    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 user and all related content has been deleted.
  • Mark SimonsonMark Simonson Posts: 1,652
    edited August 2012
    All measurements are relative to the UPM. So if you scale the UPM up or down, you need to scale all other measurements by the same factor if you want the font to appear to be the same size in use. Conversely, if you only change the UPM, you can make the font appear larger or smaller in use.
  • I would highly recommend not changing the UPM. 1000 is used almost exclusively throughout the type industry. No real advantage to change this number.
  • Jan SchmoegerJan Schmoeger Posts: 280
    edited August 2012
    Alex, the guys here are the type industry.
  • Mark SimonsonMark Simonson Posts: 1,652
    1000 UPM is required by PostScript Type 1 fonts, not OpenType CFF fonts (the kind with PostScript outlines). Although some applications (incorrectly) assume 1000 for OpenType CFF.
  • The UPM is important, but it's not the only factor that affect vertical metrics.

    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.






  • Ben BlomBen Blom Posts: 250
    There seems to be a suggestion here, that changing the UPM is a means to make glyphs look bigger or smaller.

    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.)
  • PabloImpallariPabloImpallari Posts: 777
    edited August 2012
    Ben, you misunderstand me.
    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 remember I ran into problems with UPMs above 8000. Now I read, 3333 is already problematic. But seriously, what’s the point? Stick to 1000 and use decimals. Glyphs exports decimal coordinates (technically it's more complicated than that but for the user, it's decimal coordinates) into the OTF if the font’s Grid Spacing value is set to 0.
  • Rainer, does FL support decimal coordinates? How about Indesign, Illustrator, Quark, Word & so on?
  • I don't think FL does.
    I haven't run into any issues yet. Should I post a sample font?
  • Mark SimonsonMark Simonson Posts: 1,652
    edited August 2012
    There seems to be a suggestion here, that changing the UPM is a means to make glyphs look bigger or smaller.
    I'm not necessarily recommending it, but it does work and allows you to change the overall scale of a font without touching or scaling any other metrics or coordinate values in the 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.
  • I'm working in FL now, Rainer, so I don't think Glyphs's unit-splitting capabilities will help me right now. But it's good to know for the future. Thanks!
  • Russell McGormanRussell McGorman Posts: 258
    edited September 2012
    ... a 1348 UPM to make them compatible with a particular sign-making app
    James, what was that sign app?
  • The user and all related content has been deleted.
  • Thanks.
  • How about Indesign, Illustrator, Quark, Word & so on?
    They all support fractional coordinates just fine. I tested Indesign, Photoshop and Illustrator CS3-5, Word for Mac 2008 and Word for Windows 2010.
  • I tested Indesign, Photoshop and Illustrator CS3-5, Word for Mac 2008 and Word for Windows 2010.
    This makes me wonder how far back we need to think regarding OpenType fonts and application support. Were there early OpenType aware applications that did not support fractional coordinates and are still in use? And how many publishers are still calling up type designers to get Type 1 fonts to use with their antiquated magazine workflows?
Sign In or Register to comment.