bzs@bu-cs.BU.EDU (Barry Shein) (07/06/89)
>2604(emergenc)S <<< How can I prevent this type of word separation >2839(y)S <<< from occuring? Is it troff or pscat that is >2891(broadcast)S causing the problem? >... etc. > >ttl@astroatc.UUCP ...uwvax!astroatc!ttl Tony Laundrie Are you sure this is a "problem"? It looks like it's decided the "y" needs to be over a little further than the font metric table indicates printing a "c" would leave it, probably some sort of kerning rule kicking in trying to make it look better, some character pairs need special spacing to look right. You could try using the troff .cs command to turn the whole thing off entirely and see if you're happier with that. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
rcd@ico.ISC.COM (Dick Dunn) (07/06/89)
In article <2209@astroatc.UUCP>, ttl@astroatc.UUCP (Tony Laundrie) writes: [troff example input deleted; consider the PostScript output...] > 2281(a)S > 2330(test)S > 2436(of)S > 2508(the)S > 2604(emergenc)S <<< How can I prevent this type of word separation > 2839(y)S <<< from occuring? Is it troff or pscat that is > 2891(broadcast)S causing the problem? It's not a problem. Troff is positioning output as it believes it should. Pscat is gathering the output and turning it into PostScript as best it can. When pscat finds that after one character is output, the new position is the same as the explicit position of the next character, it combines the two characters and outputs them with a single call (ultimately in a single "show"). This collection goes on as long as the implicit motion from character widths matches the explicit positioning of characters. The savings in the size of the PostScript file from this straightforward opti- mization is enormous--note that the overhead per string is 8 bytes. It is almost fortuitous (?!) that the coalescing usually joins words back together--but this is by no means guaranteed. For various reasons, not all words get rejoined, nor should you expect them to be. If you're trying to find "words" in the pscat output, you're probably going at things in a very wrong way--what you're seeing is only character sequences which were caught by pscat's coalescing algorithm. (The same thing will happen with psroff = ditroff + psdit, although the circumstances are different.) In particular, any situation which causes troff to think the natural spacing of characters should be different from PostScript font widths will cause the splitting you see. Possible factors (speaking generally) include pair kerning, differing ideas of character widths in troff and the back end, and rounding errors in width calculations. If you need to find "words", look for them far upstream, in the input to troff. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Simpler is better.