This is Macintosh-page-composition-programs in view mode; [Up]
Date: Sun 07-Mar-1989 08:44:43 From: Unknown Subject: Re: Macintosh page composition programs But but but, what about kerning? The "student" version of Xpress I used at the University of Utah didn't seem to do automatic kerning as Pagemaker seems to, albeit Xpress had a painful manual kerning option. 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! 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. Gary Crum Southern Cal >From: nedludd@ut-emx.UUCP (charles s. geiger, esq.)
Date: Sun 07-Mar-1989 15:03:31 From: Unknown Subject: Re: Macintosh page composition programs In article <15700@oberon.USC.EDU>, crum@lipari.usc.edu (Gary L. Crum) writes: > But but but, what about kerning? The "student" version of Xpress I > used at the University of Utah didn't seem to do automatic kerning as > Pagemaker seems to, albeit Xpress had a painful manual kerning option. > > 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! I believe you are indeed wrong. Adobe's AFM files have kerning tables in them, so I'm sure the printer fonts do to. Now it's time to correct me if _I'm_ wrong! Also, the latest Xpress does indeed have automatic kerning. And I kind of like their manual kerning too, especially when compared to Pagemaker, which only lets you kern in increments of 1/24 the point size of the charcters you're using--this sometimes just isn't small enough an increment! cheers, from charles s. geiger, esq. >From: greid@adobe.com (Glenn Reid)
Date: Sun 07-Mar-1989 19:04:18 From: Unknown Subject: Re: Macintosh page composition programs 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 >From: leach@neptune.uucp (Tom Leach)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.