New to Typophile? Accounts are free, and easy to set up.
Vertical metrics and extra-tall characters
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
User login
Support our Sponsors
3 Jan 2005 — 7:30pm
> 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.
Adam
3 Jan 2005 — 8:18pm
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.
3 Jan 2005 — 9:01pm
John,
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.
Regards,
Adam
3 Jan 2005 — 10:28pm
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.
T
3 Jan 2005 — 11:02pm
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.
4 Jan 2005 — 7:47pm
Thanks, John, Adam, and Thomas. I have a much better understanding of the situation now.
David