It can cause incorrect spacing in Quark (don't know if this was fixed in 8.0).

I ran into this problem just as I was almost finished with Lakeside (a connecting script), which had a UPM of 1300 something (don't ask). Scaling it down to 1000 caused big problems for me because the x-height was quite small, and also messed up all the careful alignment I had done on the connecting strokes. My solution was to scale it up to a UPM of 2000. This still left the cursor anomaly in certain older Adobe apps, but it fixed the spacing problem in Quark.

I remember that at Adobe we ran into another issue with other-than-1000 upm fonts, that occurred when making PDFs with a "third party" (non Adobe) application, and then viewing them in *newer* versions of Acrobat/Reader (8 and 9, I think). It involved an area where the PDF spec might even be ambiguous, IIRC. Anyway, the PDFs came out with the glyphs scaled incorrectly... it was pretty bad.

I think it's safe to say that it's nearly certain there will be further problems with "some applications" or workflows; it's just that we don't know for sure what those applications/workflows are, and there can even be complicated "emergent problems" from combining particular applications.

Regards,

T

My recommendation is that everyone should make a point of using a UPM other than 1000 for their CFF fonts, because the more fonts are made that way the more careful app developers will be about not assuming that any PS font has a UPM of 1000!

thanks for the feedback. i'll test in xpress extensively then...

it's a pity, scaling it to 1000 is that ugly that it would mean a lot of re-adjusting.
Maybe i should try scaling to 2000. But let's see what xpress 7 and 8 say about this.

My other question was: What happens if I set the UPM size to 1000, force the descender to -200, and still have glyphs that reach down to -300, meaning being larger than the specified UPM? Clipping? Even more dangerous things?

Sebastian, if you need to scale from 800 to 1000, try scaling first up to 8000 and then down to 1000; that will avoid rounding errors.

It is okay to have some elements of glyphs exceed the UPM height and these will not be clipped so long as the OS/2 table winAscent and winDescent values equal or exceed the actual height of the tallest glyphs. However, you generally don't want the main parts of letters to exceed the UPM height, only things like cap accents.

I like the idea that all PS glyph data tables should be on 1,000, and all TT glyph data tables are on powers of 2, but...

"... if you need to scale from 800 to 1000, try scaling first up to 8000 and then down to 1000; that will avoid rounding errors[...]"
...on some even values, and few odd values. Good luck!

"What [] if I set the UPM size to 1000, force the descender to -200, and still have glyphs that reach down to -300, meaning being larger than the specified UPM?"
It depends. Sounds like your safest and speediest method, is to convert it to an 1100 upm TT font, and leave it. TT doesn't really care about the upm value and DTP/office environments use enough TT to get along. This keeps the issue out of Adobe's emfumbling mitts, look ma no editing, and boom done.

The current bottom of node/53308 states your most likely options, and it's quite simple if you start one of two ways... which you have not.

Cheers!