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.
brown@astroatc.UUCP (Vidiot) (07/06/89)
In article <2214@astroatc.UUCP> ttl@astroatc.UUCP (Tony Laundrie) writes:
<>> 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?
<>
<>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
<
<
<I guess I ought to elaborate...
<
<All I originally wanted to do was put a logo on our troff document covers.
<I did this by printing the word "ZSELOGO" in troff, then piping the pscat
<output through sed to replace the line containing "(ZSELOGO)" with my
<PostScript program to draw the logo. That works fine for now, because the
<cover page does not change much and I have verified that ZSELOGO does not get
<split up.
<
<Next I considered the general case of including figures in documents anywhere.
<A long time ago, somebody posted a package which did exactly this-- he called
<it a troff/postscript_figure "compiler." But he suffered the same problem;
<sometimes the strings that he used ("Figure11" or whatever) got split.
<I have tried other types of strings, like ",,,11" with no luck. Sometimes
<the strings are separated by big distances, not just one line, and the order
<of the parts seems arbitrary.
<
<So my final solution (if I ever decide to write some package) would be to
<change the font type and size in troff to something that will only be used
<for figure names, then use single character letters to mark where the figures
<go. Using awk or a C program I can easily locate those letters in the
<pscat output. Got any better ideas?
[Every time I call his extension, he's not around.]
Tony's problem is going to be solved in the future, as a purchase rec. has
been turned in to get ditroff and transcript sources. Ditroff will allow
Tony to import other pre-made figures alot easier.
--
harvard\ att!nicmad\
Vidiot ucbvax!uwvax..........!astroatc!brown
rutgers/ decvax!nicmad/
ARPA/INTERNET: brown%astroatc.UUCP@spool.cs.wisc.edumsf@sneezy.crd.ge.com (Mike Fischbein) (07/07/89)
In article <2218@astroatc.UUCP> brown@astroatc.UUCP (Vidiot) writes: >In article <2214@astroatc.UUCP> ttl@astroatc.UUCP (Tony Laundrie) writes: ><All I originally wanted to do was put a logo on our troff document covers. ><I did this by printing the word "ZSELOGO" in troff, then piping the pscat ><output through sed to replace the line containing "(ZSELOGO)" with my ><PostScript program to draw the logo. That works fine for now, because the ><cover page does not change much and I have verified that ZSELOGO does not get ><split up. ><So my final solution (if I ever decide to write some package) would be to ><change the font type and size in troff to something that will only be used ><for figure names, then use single character letters to mark where the figures ><go. Using awk or a C program I can easily locate those letters in the ><pscat output. Got any better ideas? Not for the arbitrary placement of PS figures in the troffed text, unfortunately. There ought to be a troff command analogous to \special in TeX. Is there one in ditroff? On the other hand, the original problem (printing a logo) is much more easily done by copying the prolog file, modifying it to add the logo, and using the non-default prolog file. mike Michael Fischbein, Technical Consultant, Sun Professional Services Sun Albany 518-783-9613 sunbow!msf or mfischbein@sun.com These are my opinions and not necessarily those of any other person or organization.
clewis@eci386.uucp (Chris Lewis) (07/11/89)
In article <2218@astroatc.UUCP> brown@astroatc.UUCP (Vidiot) writes: >In article <2214@astroatc.UUCP> ttl@astroatc.UUCP (Tony Laundrie) writes: ><I guess I ought to elaborate... ><All I originally wanted to do was put a logo on our troff document covers. ><I did this by printing the word "ZSELOGO" in troff, then piping the pscat ><output through sed to replace the line containing "(ZSELOGO)" with my ><PostScript program to draw the logo. (and ZSELOGO got broken into multiple shows.) >Tony's problem is going to be solved in the future, as a purchase rec. has >been turned in to get ditroff and transcript sources. Ditroff will allow >Tony to import other pre-made figures alot easier. The troff2 package that I sent to comp.sources.unix to come out within the next week or two (I hope!!!!) has a particularly kludgey way to do all this. (I sent it off to Rich a long time ago, and then had to ask him to abort it because I made some rather silly mistakes. It's been sent again. Yeah, I know, promises promises) In troff documents, you can insert: .tm "M<something>" Which punts "M<something>" to stderr. "psroff" (the wrapper around troff and the actual converters) merges stderr with stdout from troff (which is the CAT codes). So, you get CAT codes sprinkled with "M<something>\0". (or is it "\n"? I misremember). "M" is an unimplemented CAT code that the back end recognizes to be an extended opcode, scoops up the characters to the end of the string, and executes it. I use the character following the "M" to specify opcode. This is how you get stock CAT troff to change typefaces in the backend. Also supported are file inclusions and "transparent copy to backend output". For example, inclusion of job-specific postscript is implemented by something like: .tm "MI<filename>" Works reasonably well, except that troff errors (eg: MM messages etc.) bugger everything up... -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425