Psroff 2.0 Trouble Shooting.... 2.1 90/07/18 (psroff 1.0 users can use this to a certain extent) These are some pointers to possible solutions to problems with psroff. After correcting a problem, you usually need to do: make all su root make install make installwidths This is assuming that you got clean compiles (you should be able to fix your own compile problems). IMPORTANT NOTE: MANY configuration difficulties can be detected by "make check". If you do encounter a problem, I suggest that you run "make check" first and correct any "ERROR"'s it reports that apply to the configuration (driver/printer) you wish to use. If you encounter problems you cannot solve and wish to ask me for help, I will want you to send me a copy of "make check"'s output.... Definitions: - LIBDIR - default /usr/lib/troff2 (config option in Makefile) LJ drivers pick up font files from LIBDIR/lib/lj. - FONTDIR - by default "/usr/lib/font" (config option in Makefile). Must be /usr/lib/font unless you have a '-F' troff, see "width option" below. - "width tables". psroff's install generates CAT compatible width tables and installs them into $FONTDIR//ft*, where "widthname" is a token denoting the "set" of widths. Postscript printers (or ditroff driving postscript) use ps. These are the only widths I distribute directly. The Makefile will install widths into widthname "lj" if you have laserjet fonts installed in the right place. - "width option", most troff's support a way of telling it where to look for the width tables. Some support -T (Xenix f'r instance). Others (Sun specifically, probably other BSD derivitives) need "-F//ftXX". Check your man pages for troff. This is should be specified by "trofftype" in lib/psroff.lib.S. If you have a "-T" version of troff, FONTDIR *must* be /usr/lib/font. If your troff supports neither -T or -F (some real old versions of Xenix, V7 perchance), you will have to install the width tables in FONTDIR directly and specify trofftype as "". Which will also mean that you can only support one set of width tables. (Unless you make binary patches to your troff) - "psroff debug" - rerun the psroff command, additionally specifying "-F" in the command line. This permit's troff's stderr to be seen. Correct any problems that it tells you about. (eg: "width option"). If you see lines of the form: M These are back-end directives and they're supposed to be there during psroff debug - ignore them. - HEADERSIZE: some troff's need an a.out.h header on the front of the width table files. HEADERSIZE (defs.h) allows you to specify an arbitrary number of bytes on the front of the table in the width file. Check /usr/lib/font/ftR (should be part of your original troff installation. Is ftR 224 bytes long? If so, HEADERSIZE should be zero. If not (eg: Ultrix, possibly older BSD's, some older Xenix, V7), you will have to specify HEADERSIZE. Ultrix wants 32. (should be the size of an a.out header structure - od -c may give you some hints). Another way to tell is to run "file" on /usr/lib/font/ftR. Does it say "data"? Then it probably needs HEADERSIZE 0. If it says "executable" or "object" of some kind, you will have to set HEADERSIZE. If you get it right, but troff is still going wierd, set HEADERSIZE 0, and set COMPILE on in the Makefile (for some reason your troff is expecting a *real* a.out.h header, but I've never seen a troff that really needs this, but this is a way of getting the size right without having to guess/write a program to find the a.out.h size. NOTE for PSROFF 1.0 users: psroff 1.0 does not have a psroff.lib file, so changes (eg: width option specifications) have to be made directly to the psroff.sh shell script. Further, in the library, many of the files are reversed - eg: lj.lib in release 2.0 is lib.lj in 1.0. Most initial problems are due to width table installation/specification - this varies from system to system and is *very* confusing. I'm sorry about that, but there's no other way. As a simple guide: if the /usr/lib/font/ftR file in your original troff installation is not 224 bytes long, you *will* have to set HEADERSIZE or (remotely) COMPILE. After successful installation/testing, most problems are due to troff errors that you don't get to see. Build/Execute gross failures: Shell scripts die horrible deaths: Particularly with error messages from "test". Does your "test" support -x? If not, make sure that you've got SHELL and STARTSHELL set properly in the Makefile (The shell scripts assume V7 and/or USG versions of the Bourne Shell. Older BSD and some BSD derivitives (aka Ultrix) need a USG compatible shell - look for "sh5" somewhere on your system). ksh, bash and ash *should* work (untested). Maybe one of these days I'll make the shell scripts work with older shells/versions of test. The makefile doesn't work: This *assumes* System V compatible MAKE. If the makefile blows (syntax errors in particular), search your system for a System V compatible version of make. Ultrix: /usr/bin/s5make. Gnumake should work fine. Most Suns need a change here too. Operational problems: NEW INSTALL: No output, or output truncated (possibly after some really wild garble in the output): Troff is probably exploding. Run psroff debug - check in particular: for troff error messages about bad -T or -F options ("trofftype" see width tables and width option above) or not being able to find the width tables (did they really install?). If troff is core-dumping, it's probably a HEADERSIZE (above) problem, but it's possibly a problem with the width of a specific character (Xenix doesn't like zero (or sometimes really narrow) characters - try tests/dumpft < > /tmp/FOO and look for errors and really narrow (0 or 1 unit) characters. Particularly \(ul/_/\(ru). Other possibilities: bad output settings (ptr and lparg), bad troff input. WORKING INSTALL (eg: it's worked fine before): same symptoms as previous. Troff is probably exploding, but probably not due to width tables. Run psroff debug. Check for and correct troff error messages (eg: line too long) in your document. This could even be troff not being able to find a file you specified to psroff. Character widths wildly and inconsistently off: Probably HEADERSIZE. Character widths annoyingly, inconsistently, but not wildly off: Remotely HEADERSIZE, more probably -T/-F trofftype omitted/wrong, or the width tables are simply wrong for the specific font or printer (you may want to experiment with the "width" option in lib/psroff.lib.S). Use "ps" for postscript printers and some others. Character widths uniformly off with ditroff: - "-R" wrong or omitted in psroff.lib.S t2arg. Check DESC file for proper value (default 300) and that the gfnttab log doesn't complain about a missing resolution during width table build. - DESC file has wrong resolution (default is 300). Try adjusting. The ps widths use 720 (in DESC file) - width option. Character widths uniformly off with non-ditroff: - wrong width tables - try using the right ones: check width option. - scaling bug in pk2ditwid/dit2catwid/gfnttab: contact me. A very few characters have bad widths: - manually adjust the widths/width/* files and cd utils; make widths; su root; make installwidths. output wacko with psfig, pic or grap (eg: overstrikes etc.): psroff doesn't work with pic, grap or psfig. Buy ditroff and throw psroff in the garbage. (There may eventually be support for pic, grap and psfig, but don't rely on it). I have some stuff to allow limited psfig functionality with psroff, but I decided not to release it at this point. Ask me if you *really* need it - '.sR "I..."' and '.sR "P...."' can more than replace psfig with the addition of some difficulty of use. output wacko during a table (output possibly truncated): run psroff debug - probably line too long (table too wide). output looks pretty good, but wierd things happen in spots: are you using ditroff features that CAT troff doesn't support? Eg: \X, \D, .sy, some "odd" permutations of \f, .ft, .fp? Font numbers > 4? CAT Troff (and hence psroff) doesn't support them. (CAT Troff does not work with pic or grap either) Looks good, but every second line has overstrikes at the end, the alternate lines are indented: ".po" + ".ll" setting too high (CAT troff imposes 7.54" limit on total). Reduce ".po" and compensate with "-O" option to psroff. I've had some rumors of *some* kinds of Xenix troff having a shorter maximum width. Right shifted when compared to ditroff/nroff/cat troff with packages other than psroff: See -O option and macro adapter description for psroff. Utter garbage output: Are you specifying the right driver? MM ".MT" macro doesn't appear to work properly: If you use a special directive (".sR" or ".fp" as modified by the adapter macros) before ".MT", .MT will get buggered up. Sorry, no workaround (though most requests other than ".fp" can be issued by psroff -P options). This isn't really a bug - a limitation of CAT troff's ability to pass additional directives to the backend without interfering with the typesetter state. Maybe one of these days I'll get around to figuring out a better mechanism. Page headers wrong or present on the first page when they shouldn't be: See previous (replace ".MT" with page header macros in discussion). line lengths a bit different from nroff/ditroff/other non-psroff CAT troff: See macro adapter discussion in psroff/troff2ps man pages. ".sR" doesn't appear to work at all: Run psroff debug - do you see lines of the form "M"? If not, you probably didn't get the macro adapters properly initialized. psroff as distributed has adapters for MS, MM and MAN. If you're using different ones, or invoking the macros by /usr/lib/tmac paths, or using no macros at all, the adapters and .sR definition won't be picked up. You will have to hand-craft your own macro adapter using common.pre and common.post, using one of the example tmac's. (all in adapters/* in distribution or LIBDIR/adapters after install) ".sR" causes breaks/font loads don't happen at the right time: It has to unfortunately. If you want to load fonts (.fp) during a line, *don't*. Issue the ".fp"'s where it's safe to have a break. Ditto other ".sR" directives. There's no restrictions on changing to an *already loaded* font (eg: .ft directives). The psroff -P option may help (not .fp's, sorry...) Some things appear really wierd (eg: strings of character repeats in page number on MM headers): Your CAT troff may not support \g (pure V7 troffs f'r instance). Experiment. You may have to bugger around with the macros to remove dependence on \g. (which is supposed to return a code denoting the output format of a number register, and is usually used to determine whether a number register has ever been set) Everything okay, but some characters missing (or wrong) on output: (ditroff drivers may complain about characters not found) Chances are that your printer or set of fonts doesn't support that character. Postscript driving should be perfect. Some ditroff drivers don't have character sets that are a superset of CAT troff. There are a few minor problems with LJ character sets. psdit, xproof, xtroff are missing a few CAT characters. You may be able to resolve these by adding translation overrides to the appropriate *.fonts file (see jt.fonts for examples). Some ditroff's have different meanings for the same character spec. ("@" in some ditroff drivers is a different character) My ditroff driver dies with errors about lines starting with "#": define NOCHATTER. My postscript printer server gets upset: define NOCHATTER I get postscript printer errors on last page, or last page missing: Have you got a DEC LN03 or some other printer that doesn't like trailing control-D's? Define "NOCONTROLD" in defs.h Ditroff driver doesn't work/gives errors: check, recheck, and check again for ditroff backend config (lparg/ptr in psroff.lib.S). Try "psroff -t" and then hand feeding the stdout to your backend manually. Experiment with "-d" setting in t2arg in psroff.lib.S. If related to specific characters, maybe adding translation overrides in the appropriate *.fonts file will help Laserjet printers get confused and loses settings (eg: copy count etc) Be aware of the fact that lj.lib has a RESET command. If you have some sort of spooler that's emitting commands to the printer outside of the control of psroff (eg: copy count set before psroff output), you may have to change it. Laserjet: wrong font selection (particularly when the result is 10 point Courier), troff2ps compaining that it can't find a font file: - lj.fonts incorrect. - Don't have any good font files - buy some good ROMAN8's for Roman, Italic and Bold, or use TeX fonts and "make buildljfonts". Laserjet: lousey/wrong/missing characters (non-S font): - You got crummy fonts. Go buy or steal some good ROMAN8's in Roman, Italic and Bold at CAT troff's supported point sizes. TeX's PK fonts will work, but non-alphanumeric characters will often be wrong (particularly box drawing and backslash) - Get a Pacific Page or HP Postscript cartridge. My laserjet stalls, gives "too complex" messages, doesn't switch fonts sometimes: - Some HPLJ clones don't support incremental downloading. undefine INCR and try again. Plain laserjets (the old ones) don't support font downloading at all. Sigh... - Ran out of memory - (INCR on): simplify document to use less fonts or reduce MDLF. - Ran out of memory - (INCR and PARTIAL off): turn on PARTIAL - Too many fonts previously loaded - adjust PRELOAD. - double check MDLF. Manual pages look great except the page footers are at the top of the next page. MM and MS work fine. - You're IBM AIX right? Sigh.... The man macros in AIX explicitly set page length to something other than 11 inches. Supply "-rM1" to psroff, and the macros will select 11 inches. Or, you could insert a ".nr M 1" the beginning of adapters/tmac.an. SQTroff ditroff backend sometimes barfs on psroff ditroff output: It do do that don't it? SQTroff ditroff format is apparently slightly different. Then again, if you got SQTroff, why you have psroff? xproof sometimes dies with "too many font" messages: - AT&T's fault. (Each symbol character is a separate font, xproof is configured for a maximum of 50 or so fonts... duh...) The Bell Symbol (\(bs) isn't: It ain't supposed to be. Psroff is wonderful: Thank you!