UPM in a family with web fonts.

James Puckett

What are other people doing with UPMs when developing a family that will include screen fonts or developing screen fonts for an existing family? I am working on a family that will have the usual light–black range of weights for general use as well as a RIBBi set for text on screens. I would like to keep the big family at 1000 UPM so it matches up well with my existing fonts and so I can sell OTF format fonts to people who still believe TrueType fonts will blow up a RIP. Is there any rendering advantage gained from doing the TTF web fonts at 2048 UPM font rather than 1000 UPM for both?

TimAhrens

I have worked with all kinds of UPMs for TT-based webfonts and never experienced or heard of any problems. Having a greater UPM for the TT fonts gives you a more precise curve conversion, though. I would use multiples of 1000, though, so as to prevent rounding errors for the nodes. I typicaly work with 1000 or 2000 UPM.

Georg Seifert

I usually draw on a UPM of 1000. Then either use the 1000 for the ttf, too or use a custom parameter (in Glyphs) to scale the instances to 2048 on export. The scaling will use the unrounded result of the interpolations so you actually get a better resolution then in the CFF fonts.

John Hudson

There is a measurable but tiny performance benefit during scaling if a TTF has a UPM that is a power of 2, which is why it remains Microsoft's recommendation. However, there are no significant problems with using any UPM in a TTF.

[There remain problems with using a UPM other than 1000 for PS fonts in some third-party PDF creators. Which sucks because not all of the world's writing systems are well served by such a coarse grid, especially in refined designs intended for display use.]

Deleted Account

The RE fonts are all on 512.

James Puckett

What’s the cap height of the RE fonts? Are you going over 512 and working around it with the vertical metrics?

Göran Söderström

All Letters from Sweden webfonts are 256.

John Hudson

If you're making fonts specifically for text sizes on screen, then a low UPM is a grand idea.

James Puckett

Is the low UPM just good for keeping file sizes down, or does it have other advantages?

Deleted Account

RE heights vary but don't escape the em. My taught process was that 1024 and 2048 are overkill for the web and 1000 sucks, being too low for many things, too high for the web, and hard to divide in my head. Few web fonts will get used past 256 ppm, ever, but I doubled that, figuring its the best compromise. I don't know how much it controls file size, but as web fonts like RE expand to larger glyph repertoires, kerning pairs and hints, I assume the 1/4 size em saves some space along the line. And if not, we can always scale them up to 2048 in a nanotypesecond and loos nothing.

TimAhrens

How does a smaller UPM save file size (apart from creating somewhat fewer curve points on PS-TT conversion)?

John Hudson

It takes fewer bits to store a two digit number than a three digit number, and fewer bits for a three digit number than a four digit number. Large amounts of data in fonts consists of numbers --point positions, advance widths, kern and other positioning adjustments --, so the more of these that can be expressed in smaller numbers, the smaller the font file will be. I've seen pretty dramatic size differences between fonts whose only difference is internal scaling.

BTW, it should be evident that what we're talking about here is not the size of the UPM value per se, but the scaling of outlines and other data relative to that UPM. Simply changing the UPM value of a font but leaving the outlines and other data unscaled will not affect file size (but will affect text size!)

John Hudson

Here's a quick test I did with a TTF version of Brill Roman:

UPM = 1000 = 1.48 MB file
UPM = 500 = 1.3 MB file

That's a c.13% reduction in file size just by changing the internal scaling of the font.

PabloImpallari

Another way to reduce file size is to use GPOS kerning only, removing the KERN table.

Or maybe... Relaying on good spacing and omitting kerning altogether???
@David: Removing the kerning from BentonModernRE was a decision made on purpose? or is it a bug?

Deleted Account

John knows all I know abou

Deleted Account

t... Hmmm... Sorry, ... File size reduction by em-smalling.

@Pablo, I decided if there was not going to be kerning in all browsers for a while, that I'd fit the uppercase diagonals with large kerns and leave it at that until update time, which I like about serving web fonts.

Jackson Showalter-Cavanaugh

leave it at that until update time, which I like about serving web fonts

Hear! Hear!

TimAhrens

Thanks for the example, John. Did you change the UPM before converting to TT curves? Could it be that the size difference is largely due to a different number of control points?

I made a test myself with JAF Bernini Sans Regular 1000 UPM vs 2000 UPM. Since we are talking about web fonts, the size difference of the raw TTFs is almost irrelevant; I was more curious about the difference in WOFF and EOT. Interesting to see that the (relative) size difference is not "compressed away" but even amplified.

• raw TTF: 1.2% size difference
• gzipped TTF: 1.4% difference
• WOFF: 1.7% difference
• EOT: 3.9% difference

Comparing it to John's example, it seems that the effect of the UPM change varies greatly between different fonts.

Oh, and another hot tip for reducing the file size: Don't put the entire EULA into the "License" field in FL. As per OT spec, it's supposed to be a shortened "License Description" anyway.

Matthew Butterick

In terms of web performance, byte-shaving is a much less useful form of optimization than, say, consolidation of http requests. Which isn't to say smaller files aren't better. They are. But file size is often not the primary bottleneck. So be wary of turning your production process into a pretzel just to save 5-15% in file size.

Deleted Account

Well, then there is subsetting, the granddaddy of them all. But no matter how many glyphs you plan to remove, there are always some left. If we could solve that, we'd have really small fonts.

Jackson Showalter-Cavanaugh

But file size is often not the primary bottleneck.

I switched www.theharrietseries.com to inline base-64 encoded .woffs the other day. The total file size increased 38% but the site is loading about 0.5-1.5 seconds faster because it has twenty less server requests (for the over 90% of visitors who can use .woffs, it is definitely slower for those slumming it on eot/ttf).

Matthew Butterick

Yep. I used the same technique for my Concourse web specimen. (Except that I don't serve eot/ttf.)

TimAhrens

Matthew: Your point does not invalidate the discussion of file size. We are all aware of the other aspects of web performance but thanks for teaching us.

Jason Campbell

@timAhrens, but the file size savings in changing the UPM is in changing distances to smaller bit size. According to the TT spec:
--------
BYTE or SHORT xCoordinates[ ] First coordinates relative to (0,0); others are relative to previous point.
BYTE or SHORT yCoordinates[ ] First coordinates relative to (0,0); others are relative to previous point.
--------
So the main savings here is in getting the coordinates saved as bytes(8bit), not shorts(16bit). The tools will use the smaller value when possible. So David's use of 512 helps because the relative distance coordinates are mostly going to be less than 256units. If you're only changing from 2000 to 1000, you won't see much change, since your average distance will still be more than 256, and require a short to save the value.

The ultimate file size for this would be 256upm, and there are many East Asian fonts that are built on this, since file size is so important in that case. However you can imagine that is a very coarse grid to try to draw on.

Matthew Butterick

But no matter how many glyphs you plan to remove, there are always some left. If we could solve that, we'd have really small fonts.

Well, that's similar to how Typekit improves webfont performance on its own site: by not using them.

Deleted Account

>...coordinates are mostly going to be less than 256units.

Mostly less than 256 and also less than -256. Though the 256 unit em will almost assure this, it's hard to ensure the ability to design all RE styles of all scripts at a common upm, like is possible with 512. And if someone doesn't care about anything but size, including contour accuracy, a 512 em can be scaled down to 256 pronto.

Göran Söderström

128 is the new 256.

( Having that said I must confess that my first post was a joke if that wasnt clear, we don't use 256 )

Deleted Account

Oh... I was waiting font a web font family called "Sweden."

Göran Söderström

My god, is that name not taken already?

Deleted Account

Oh, how about "Sweben"?