Vertical metrics and extra-tall characters

magister's picture

From the information in a previous thread (belated thanks to John Hudson!) I solved the problem of Mac and Windows having different line spacing with my font. While fixing the cross-platform issue I took a close look at all the vertical metrics and have the following question.

I have a few characters (capitals with two accents and h-circumflex) that are higher than the WinAscent value. They are clipped off on screen in most Windows apps, as would be expected, but they print OK on the two printers I have. Is it safe to assume that all printers will handle them OK? I think users will be happy if they print correctly (and since they are rare it's not likely that they will appear right under a descender, which would look bad).

Alternatives are to make special low versions of uppercase vowels for use under double accents or to change the WinAscent value. I tried the former solution and don't like how it looks. The latter is not a good idea since users who upgrade to a new version of the font may find their page breaks changing in existing documents. Is there any real danger is just leaving things as they are?

Thanks - David

twardoch's picture

> Is it safe to assume that all printers
> will handle them OK?

No, it is not safe to make these sorts of assumptions. In particular, PCL and PostScript printers may print them OK but Windows GDI printers may exhibit the same problems that occur on screen.


John Hudson's picture

David, your best bet is to leave things as they are, since the options for changing them are more generallt problematic than the problem itself. There is a chance that some printers may reproduce the clipping, but in my experience this is very rare. Even MS ship fonts that have some tall glyphs clipped, and they maintain the WinAscent value for exactly the same backwards compatibility issues that you describe.

Adam, can you suggest some possible GDI printers that might have this problem? I'd like to track one down and run some tests. Also, I'm assuming that this work-around would avoid the problem, even on such printers: print to PDF, then print PDF.

twardoch's picture


at your service:

Brother HL-720, HL-730, HL-820, HL-1020, HL-1030, HL-1040, MFC-4650, 6550MC, 9050

HP DeskJet 710C, 712C, 720C, 722C, 820C, 1000C

HP LaserJet 1000, 1005w, 1010, 1012

Lexmark 1000, 1020, 1100, 2030, 2050, 2070, 3200, 5000, 5700, 7000, 7200, Z42, Z43, Z51, Z52

Minolta QMS PagePro 1100L (not 1100)

Oki Okipage 4w, 4w+, 6w, 8w, 8w Lite, 8z, 400w

Panasonic KX-6100, KX-6500, KX-P7100

Samsung ML-200, ML-210, ML-1000, ML-1010, ML-1020, ML-1200, ML-1210, ML-1220, ML-1510, ML-1710, ML-1710P, ML-4500, ML-5080, ML-6040

AFAIK, all above are Windows GDI printers (also known as host-based Windows printers). I would be glad to hear myself if any of the printers mentioned exhibits that particular problem.


Thomas Phinney's picture

One quick way of looking at it is that 95% of all common inkjet printers are GDI devices. So if you have clipping on-screen, it's likely to be a problem in print for a significant chunk of customers. Even high-end graphic professionals often do rough proofs on non PostScript color inkjets.


John Hudson's picture

One quick way of looking at it is that 95% of all common inkjet printers are GDI devices.

Wow, I had no idea it was that high.

magister's picture

Thanks, John, Adam, and Thomas. I have a much better understanding of the situation now.


Syndicate content Syndicate content