greid@adobe.com (Glenn Reid) (03/08/89)
In article <15700@oberon.USC.EDU> crum@lipari.usc.edu (Gary L. Crum) writes: >Does either utilize the PostScript kshow operator? This brings up >a higher-level philosophical point. Shouldn't fonts be distributed >with kern tables created by type designers? I don't think kern tables >of any sort come with the Adobe fonts. Correct me if I am wrong! Adobe fonts come with kerning tables as supplied by the manufacturer of the original font. This data is considered to be "Medium", where there is a choice between "Tight", "Medium", and "Loose". There are approximately 135 pairs of letters in the kerning tables, and there is no meaningful track kerning data, unfortunately. Since there are only about 135 of the possible 65,000 or so pairs, the data has to be conservative (Medium). There is a kind of visual threshold in kerning where, if you don't supply values for ALL pairs, you can clearly see the ones you "did kern" next to the ones you "didn't kern." By supplying data for only the worst and most common cases (like "AW", "WA", "To", etc.), you can bring these pathological cases into reasonable agreement with the rest of the text, and the eye does not catch on any particular combinations. It is very, very tricky, however, to use a partial set (not all 256^2 combinations) of kerning data effectively. The pair kerning data supplied with the fonts, since it is essentially intended for automated "evening out" of the spacing between some of the worst-case pairs, is really only good for large bodies of text, and is not enough for setting real display type. Display type is best kerned visually, by hand, anyway. For that, the more important issue is to have outline fonts on the screen, not to have kerning data. You simply can't see what you're doing accurately enough with bitmap screen fonts (especially when you zoom in for finer detail). Whether or not the data is used by the application, and whether "kshow" is used (or some other means of positioning characters), is up to the particular program. "kshow" is not the best way to do kerning if pairs appear only occasionally within the text, since you pay the overhead for every single character that gets printed. It is better to break the strings at the kern pairs in the application, and generate separate calls to "show". >I was rather surprised when I found that even the demanding aesthetic >taste of Steve Jobs tolerated the omission of kerning. I expected NeXT >software to use kshow with pretty kerned characters exclusively. But >then, I expected the NeXT DPS server to anti-alias outline edges as well. >Maybe I'll be pleasantly surprised when we receive release 0.9. Omission of kerning in what? The application software that runs on NeXT can easily enough support kerned characters. So far, there is too little of it to critique. The fairly simple word processor was ported from another system, and does not yet support kerning. Beyond that, where is kerning missed? Oh, and also, the Display PostScript System has new operators called "xyshow" and "xshow" that are much better for kerned text than "kshow". As for ant-aliased outline fonts, I'm not sure anybody has ever done it. Bitmapped fonts, yes, but outlines, I'm not so sure. Glenn Reid Adobe Systems PostScript Developer Tools & Strategies