Greetings!

I have been working for the past few months in Illustrator on a display family with lots of alternate glyphs and ligatures and would like to begin the process of creating a fully functioning OT font in FontLab 5.0.2. (on Mac X)

I have never used FontLab before and this business of a UPM value of 1000 throws me already off. The number 1000 seems such a unyielding beast regarding it's compatibility with other numbers. It cannot be cleanly divided by 3 to start with. Could I use 1080, for instance? (With the exception of 7, it is divisible by any number between 1 and 10 and by 12, 15, 18, etc.)

Or is s there a way to get around those rounding errors by choosing a number lower than 1000? In my case, the number 864 would allow all points in all weights to fall precisely on the grid. (the design has a few decorative elements, like seamless patterns for each weight, for instance, which I would like to remain seamless)

Any input on this would be greatly appreciated!

Thanks,

Peter

This question has been asked answered in detail on Typophile many times. The short answer is you can use a huge variety of UPMs - but as you have guessed the math can matter. In general 1000 is the size used but for instance Microsoft fonts are made to 2048. You can also use 1080 - not a problem. But for the max info enter this into google:

site:typophile.com UPM

All the details to this question are there. BTW Typophiles search doesn't always work for me and I have not spent time working out if the page the browser or what so save that Search. You can substitute new search terms for 'UPM'.

Any chance that you will post an image of what your up to?

Yes, scaling down anything that was scaled up should result in exactly the same (not only consistent stems) if it was not modified. This applies even if it was scaled by an odd value, say, scaling from 1000 to 1250 and back.

Hello Tim, thank you. For this typeface I am working on I had to choose a UPM of 2000, otherwise curves become disharmonic (it’s quite condensed). I started at 1000, then I modified some curves after scaling it to 2000, but scaling down back to 1000 produces some breaks in curves, and the curves end up being not harmonic and unpleasant.

I think I will keep the UPM at 2000, even if it is in an Opentype-flavored format. Since I have no intention to produce a Truetype-flavored, I choose 2000, so – just in case – I could scale down.

I would prefer to keep 2000, anyway.

Someone knows which software could have problems with a Type1 or Type2 font with an UPM of 2000? Is the issue mostly related to printing engines or even to software? Thanks.

Some clarification from Microsoft's Greg Hitchcock:

I'm fairly sure the reasoning in TrueType was all about performance. Integer math was much quicker than floating point. TrueType fonts preferred having the Units per EM (UPM) as a power of two because in all of the scaling of the outlines, one has to continually divide by the UPM. When that is a power of two it is much quicker and can be implemented with a "shift right" instruction.Of course higher UPM size give greater accuracy to the outline data, giving the equivalent of fixed fractional precision, but there is a trade-off in data size. For TrueType, outline data is typically stored as relative distances from the previous point. If the relative distance could be stored in a byte, it would be, otherwise it was stored in a 16-bit value.

The higher the UPM, the less likely relative distances would fit into a byte. For some of our early Japanese fonts, we used 256 UPM in order to reduce the outline data size. 2048 UPEM was common in TrueType because it seemed like a good balance between data size and accuracy. The range for TrueType and OpenType is between 16 and 16,384 inclusive.

Also see:

http://typophile.com/node/30727

Cheers,

Adam

Keep in mind that scaling from an UPM 2000 down to 1000 is the worst case: about every other value has a rounding error of 0.5, which can esily add up to stem inconsistencies. So generally avoid scaling things by exactly 50%.

A question for Tim (assumed he will some day pass here again… :-) ):

If I have upscaled my EM size to 2000 from an original of 1000, and then I scale it again to 1000, stem size would be kept consistent, if I have not modified it, right?

I mean, the rounding error applies only where there is a value which you can’t scale at 50%.

BTW your site is not showing up for me.

Hi Eben,

thanks for the search tip. The results give me plenty to ponder. My site is inactive right now.

P

I've used UPM up to 16000 (for personal use)

Your icon is cool so I wanted to see more...

thanks – I will show, but need more time...

Writing off the top of my head now:

The maximum UPM size permitted by the OpenType and TrueType specifications is 16,384 (http://www.microsoft.com/OpenType/OTSpec/head.htm), and this is the value that FontLab Studio also permits as a maximum.

You need to keep in mind that the UPM size controls how glyphs will be sized at a specific point size (i.e. the point size chosen by the user in an application always corresponds to the UPM size of the font). If your UPM size is 2,000 and the user chooses 10 pt type, any glyph that will be 1,000 units high in your font will be exactly 5 pt high in print. Typically, in text fonts, the height of flat uppercase Latin letters such as E, H or I is 70% of the UPM size. So if you pick a non-1000 UPM size but you want for your font to go well with other fonts available on the user’s system (i.e. so that it’s not untypically small or untypically large in relation to other fonts), you should make your uppercase letters roughly 1,400 units high in a 2,000 UPM font. Of course this is just a rough estimation -- it can range from 1,100 to 1,600 units and will still be within the normal range. If your lowercase is quite large, you may want to make the uppercase appropriately smaller, somewhere around the 1,100 end. (For a 1,000 UPM font, all these values should be cut by half, obviously.)

The Type 1 specification states that absolute glyph coordinates must not exceed the range of –2,000 to +2,000, in both x and y directions (http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF section 3.3). This means that according to this specification, *regardless of the UPM size*, none of your extrema points should have the x or y position larger than ±2,000 units.

While in the Type 1 specification states that the general limitation is ±2,000, the Type 1 spec supplement states that the most important implementations have higher limites: the Adobe PostScript RIP that is built into printers and imagesetters supports glyph coordinates up to ±4,095 and the Adobe screen font driver (ATM/CoolType) supports coordinates up to ±8,191. So these are the more important limitations to observe.

All those limitations are also valid for OpenType PS fonts as they are being converted to Type 1 fonts when sent to a PostScript printer.

Adobe recently released a set of OpenType PS fonts with the UPM size of 2,048 (Adobe Arabic, Adobe Hebrew, Adobe Thai) in which there are a few very wide glyphs in which the x coordinate is about 3,500. This exceeds the original Type 1 limitation of ±2000 but is still within the Adobe PostScript RIP limitation of ±4095.

It seems that, regardless of the chosen UPM size, the maximum glyph coordinates in an OpenType PS (.otf) and Type 1 font is ±4095.

In FontLab Studio, you can check the maximum glyph coordinates in Font Info / Metrics and Dimensions / Key Dimensions / Font BBox. The values listed there are in order: (minimum x, minimum y) - (maximum x, maximum y). Make sure that the absolute value of neither of the numbers is larger than 4095.

FontLab Studio currently has an internal implementation limit for glyph coordinates of –32,767 to +32,767. This means that very high coordinate values (e.g. over 10,000) might cause problems at geometric transformations (scaling, rotating etc.). You can observe the effect easily if you scale something in FontLab by 1000% several times -- you will see that the glyphs "implode".

Altogether, it is not possible to give one definitive answer of what the maximum UPM size and maximum glyph coordinates should be. For reasons of conciseness (one of the glyph design principles recommended by the Type 1 specification), the designer should not choose a larger UPM size than is needed for the precision he’s looking for. If the precision offered by the UPM of 1000 is not sufficient, the designer should choose 2000, and failing that, higher values such as 3000 or 4000 — while on the other hand keeping in mind that all glyph coordinates should fit within the ±4095.

Depending on the font format (OpenType PS or TT) the tool choice (Fontographer or FontLab Studio) and backwards-compatibility concerns (does the font really have to print on printers or imagesetters made in 1992?) the limits are different. Also, many of those limits are not "hard" or specified by any vendors, they’re empirical estimates that people found after struggling with some bugs in specific devices.

Adam

Having said that, using a UPM size that is *lower* than 1000 is absolutely no problem, and using a UPM size that does not end with three zeros, and is not a power of two, is also no problem. So using the UPM size of 864 is just as fine as 1080 or 997 or 115, or even 13. In fact, I have seen pixelfonts designed on a 13 unit UPM size, with each "pixel" square was exactly one font unit high and wide.

A.

If you want a UPM value higher than 1000 keep in mind the rounding errors when you scale the font up or down.

I typically use a UPM of 3000 as this is obivously lossless when scaling up (all values are multiplied by 3), and when scaling down the maximum rounding error is only 1/3, which is the lowest possible maximum rounding error you can get when scaling down.

Tim, what do you mean by "scale the font up or down"?

A.

I was assuming that fonts with an UPM of 1000 are to be generated in the end and also that you might only temporarily want to increase the UPM value for certain operations or design steps. In that case, when changing the UPM you would check the "Scale all glyphs according to UPM size change" checkbox because otherwise you would not effectively change the "resolution". This implies "scaling", i.e. multiplying the coordinates of every node by a certain number - which can lead to rounding errors and stem weight inconsistencies.

If you only want a slightly different UPM you may not need to scale the glyphs. However, I do not understand what would be the benefit of that.

Peter, what do you mean by "the number 864 would allow all points in all weights to fall precisely on the grid."? What grid are you talking about?

Back in 1995; I wrote something about UPEM for Microsoft. This was in relation to the 'head' table in a TrueType font and why 2048 was chosen for TrueType by Sampo Kaasila and Apple Computer. Basically it is because division on a computer (especially when TrueType was made) is slow and division can be achieved quickly by shifting bits if the values are powers of 2.

* unitsPerEm should be a power of 2 (2048 ideally).

What is a power of 2?

A value that is the product of 2 to the power of 'n'. For example, the ideal value of unitsPerEm is 2048. This is the product of 2 to the power of 11.

Why a power of 2?

Division on computers is a very slow operation. One way programmers get around this problem is to use a technique of shifting bits for division. When a value is a power of 2, division can be performed by simply shifting the bits in the binary of that number. This is extremely fast and efficient.

This method is similar to dividing by ten in a decimal system. To divide 1000 by 10, you only need to move the decimal place one value to the left. The result is the same as 1000 divided by 10 or 100.0.

Why 2048?

2048 units were chosen for a few reasons:

* It is a power of 2 (2 to the 11th power).

* 2048 is a high enough value for good precision in rendering.

* 2048 is a low enough value to be processed efficiently by microcomputers.

In the Asian fonts for Windows, MS Mincho and MS Gothic, it was necessary (at the time of their release) to choose a lower value (256 units) because of the file size of these font files.

The actual units per em value is a balance between the amount of processing power, the complexity and size of the font file, and the amount of precision that can be obtained with this value. A low units per em value would result in less quality in the output, but be faster to process. A high units per em value would produce a higher quality output, but be slower in processing.

Today, computers are more powerful than ever and the use of large fonts with thousands of glyphs is becoming more common, especially with Unicode and OpenType fonts. With today's computers, we suggest the 2048 units per em value as still the best value for all fonts of any size, including large Latin or non-Latin script fonts.

If you have designed legacy fonts at 1000 units and later decide you need more precision, you can double the UPM to 2000 units in FontLab without any rounding errors. If you go to 2048 from 1000, won't there be rounding errors to contend with? Is the computation speed difference between 2000 and 2048 enough better, given todays computers, that it is worth the tweaking of outlines to overcome rounding errors?

Assume this would be a font with extended Latin, Greek, and Cyrillic scripts only--no Asian font complexity.

ChrisL

Is the computation speed difference between 2000 and 2048 enough better, given todays computers, that it is worth the tweaking of outlines to overcome rounding errors?

Good question!

Maybe it's a choice: Either you care less for speed (provided there is still a significant difference). Or you care less for metrical identity of possible .otf and .ttf versions (or make a .ttf version only). In the latter case you could use 2048 instead of 2000 without rescaling outlines, which makes the .ttf version look a bit smaller.

Thanks Karsten! I didn't realize all ttf fonts had to be 2048 to scale properly. Would a .otf font on Windows also have to be scaled to 2048?

ChrisL

Karsten, you are not saying you have to pick 2000, 2048 or 1000 UPM for any format are you? What I think you are saying is just that if you do choose 2048 for speed in TT & 1000 ( or 2000 or whatever but not say 1024...) in OTF (type one flavour) you will be choosing speed over exactly identical data eg 'metrical identity'. Or if you choose to keep identical or proportional sizes, eg 1000 & 1000 or 1000 & 2000 or even 3000 you are choosing exactness. If you choose 2048 for both TT & OTF then you get both too. But maybe I am not getting you here.

For instance: when you write, 'which makes the .ttf version look a bit smaller.' do you mean that the 2000 UPM font will look smaller than the 2048 fonts? Or that it will look smaller than the 1000 UPM version? In either case I don't follow your thinking because isn't visual size vs. stated size (pt em etc) exclusively a question of the glyph's proportion in comparison to the chosen UPM itself?

BTW, Adam, thanks for yet further subtle distictions on this topic! Awesome.

Hello Eben, I only addressed Mr Lozos question, how to change the UPM but avoid rounding errors if you want to change it. So it was a what-if thing.

That UPM be a power of 2 is a recommendation for TT-OpenType fonts, but not for OT-OpenType fonts. (As far as I know.)

I think if I had a font with PostScript-outlines and UPM of 1000, I would not change the UPM for generating a TrueType-outline version. So I am myself curious about the actual speed advantages of, say 2048 vs 2000 in a TT-OpenType font.

What I mean with "looks smaller" is: Imagine the same outline (not rescaled) once on an em-square/body of 2000, once on an em-square/body of 2048. In an application, if you choose 12 pt with both versions, the latter will look a bit smaller since the body is larger.

Karsten

Just to clarify this:

What Karsten means would be done in FL in two steps:

1. changing the UPM from 1000 to 2000 with “Scale all glyphs according to UPM size change” checked.

2. In a second step, changing it from 2000 to 2048 without that checkbox checked.

I think this is quite an elegant solution to the problem.

Eureka! Thanks Tim! That certainly makes the light come on in my aging cranium! The amount smaller would be insignificant.

Karsten, that is a brilliant solution!

ChrisL

Isn't 2%--48/2000--significant when it comes to typefaces?

If you just tell FontLab to generate a TT font from a font with Bezier curves at 1000 UPM, it will convert the outlines and keep the 1000 UPM, right? Is this a problem? What does FontLab recommend?

> Adobe recently released a set of OpenType PS fonts with the UPM size of 2,048

> (AdobeArabic, Adobe Hebrew, Adobe Thai) in which there are a few very wide

> glyphs in which the x coordinate is about 3,500.

What does it mean? Fonts with the UPM size of 2,048 in which the x coordinate is about 3,500? I understand UPM 2,048 is the total number of points?

> Adobe PostScript RIP limitation

> of ±4095.

How does it translate to the UPM size?

Thanks.

Karsten, & Tim:

Thanks! Okay, that's what I thought! Whew. I feel better.

What I especially want to know is what in your wisdom do you choose to work in today? 1000 UPM? 2048? Why?

Are you considering a change?

What about the rest of you? As far as I can recall I have not read of any disadvantages to working in 2048 so given it's advantages - why not? So far I have really only worked in 1000.

I have to admit that the idea of giving a customer two diferent 'sizes' of fonts in TT & OT or t1 seems like a really bad idea. Or phrased differently It seems like maintaining preceived size is a good idea. But so does maintaining ( as much as possible ) identical data/forms accross formats.

What I especially want to know is what in your wisdom do you choose to work in today?

Which UPM is ideal to work in, meaning the design work regardless of technical issues, that is an interesting question. I typically switch between UPM of 1000 and 3000. As said before, scaling up is lossless as all coordinates are multiplied by three and scaling down to 1000 has relatively small rounding errors. Keep in mind that scaling from an UPM 2000 down to 1000 is the worst case: about every other value has a rounding error of 0.5, which can esily add up to stem inconsistencies. So generally avoid scaling things by exactly 50%.

On the other hand, it is easy to forget that even a UPM of 1000 is much more than the typical printing resolution: For example, at 1200 dpi and a type size of 60 pt you have a 1:1 relation between dots and font units. This means that in order to change something only by one dot at, say 10 pt you need at least 6 units in Fontlab, even if that looks very much on the screen.

For me, the difference between 1000 and either 2000 or 2048 matters only in certain situations. More-so in very light weights and with italics and scripts. Cases where a join is being made and a hotspot is the demon to avoid. a fine hairline script would be in most need. You just need those between angles of control handles to manage the diagonal intersections pleasantly. Your average weight vertical font won't be a problem at 1000.

ChrisL

"So I am myself curious about the actual speed advantages of, say 2048"

MS says it is "substantial". What makes it not worth investigating further, is that scaling Up is hardly a type-shattering problem in type design. If someone is concerned about scaling from 1000 to 2048, see your local FL Constabulary for Up scaling with hinting in FL. On the other hand to be fair, they are supplying hinting of the output to solve the more generally problematic Down scaling of type.

"changing the UPM from 1000 to 2000 with “Scale all glyphs according to UPM size [...then] changing it from 2000 to 2048 without that checkbox checked.

I think this is quite an elegant solution to the problem."

This is a solution. It's best employed on 1000 dpi fonts that have no metric history in the outside world as it leaves 1000 and 2048 fonts unmatched vertically. It also says you didn't care for the original relationship twixt design and em by a specific factor. ;)

There have been a lot of threads here, but fabric fails to form. ;)

There are two variables in the designer's UPM decision tree: the memory and processing of the composition system, and the characteristics of the type design.

The OS's big problem with "real Typography" was always that the UPM's size alone is not enough of answer upfront "how big?" how much memory and etc. ... So, to handle Typography, there are now more numbers and tables in the font formats to answer the question in enough detail. But still, there's got to be a gross maximum unit system upon which, the UPM exists, and the type occupies, mostly within, but not exclusively within the em. That's the truce — we have 16,384 to build: an em (TT) and all the extent we need. But if you use it all on the em! (8x2048 you fools!), don't go outside of that 16,384, please, it could have consequences for all of us. . .

Design's big problem with the EM is when the level of detail is under-whelmed by resolution. 1000 rarely needs to change for "normal" design detail. 2048 rarely needs to change for "any" design detail. The Linotype library was built on 8000 something. The Bitstream Library was built on 4320, and the Adobe Library was built on 1,000. So, a designer's got to have something very special to render in a master (small relative to the upm, or large relative to the user), to make one choose something beyond 2048.

I hope that's all true, still.