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?
0
Comments
[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.]
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!)
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.
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?
@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.
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.
--------
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.
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.
( Having that said I must confess that my first post was a joke if that wasnt clear, we don't use 256 )