clewis@eci386.uucp (Chris Lewis) (03/10/90)
[Manually generated followup - our machine doesn't get comp.sources.wanted, so until I get our feed fixed, I've redirected followups to comp.sources.bugs so that I can see them. That is, if our feed works at all... Thanks to Greg Woods for mailing me this article.] exnirad@brolga (Nirad Sharma) writes: | martin@mqcomp.oz (Martin Foord) writes: | >Does anyone out there have a troff to postscript converter that is | >fairly reliable. I extracted from the net `thack' several months ago, | >but this has proved to be fairly bug ridden and not very powerful. | >Is `psroff' a public domain troff to postscript ? It's copyrighted, but freely distributable for non-commercial use. I should know - I wrote it. FTP access for latest released version (Release 1 patchlevel 7): [ On Tue Jan 23 7:12 (Re: "psroff is on gatekeeper"), Paul Vixie wrote: ] >FTP access to psroff patched to level 7: > Tell people to go to 16.1.0.2 (gatekeeper.dec.com) as anonymous, > in /pub/misc/psroff-pl7.tar.Z. | We have been using psroff for about a month now and it has given us no | problems. It seems to work quite happily with the CAT troff on our XENIX | machine and handles all the tbl and eqn codes that it has been fed. That's good to know. There is a psroff mailing list - if you want to join, drop me a line... (Though, to OZ, I'd probably have to get someone down under to approve and have a mailing list exploder...) | There is one problem, though. The logical PostScript page is shifted down | a bit. I assume this is due to psroff being set up for the American legal | paper or whatever. This is especially noticeable with man pages where the page | nmber at the bottom is left off. Otherwise, everything in psroff seems fine. | Anyone who has a fix for this - HELP ! Chances are that this is a page length problem. Does a multiple-page print from psroff shift a bit more on each successive page? That means that troff has a different page length specification than psroff does. What you need to do is measure your paper length, and specify the following to psroff: -rL<value><units> Where "value" is the length of the page, and "units" is "c" or "i" depending on whether value is centimetres or inches. A4 size paper needs -rL29.7c. "Executive Size" (HPLJ nomenclature) needs -rL25.7c. This is documented in the psroff and troff2ps manual pages, and is completely compatible with MM "-r<reg>" mechanisms. In later versions of psroff (patchlevel 6+ I think), macro adapter packages are supplied to retrofit -rL and -rO so that -man and -ms macros also understand this nomenclature. But, in your case, it's probably that troff's default page length (or settings in the macro packages) is correct, but psroff's default is 11 inches. If this doesn't work, let me know. I'll need: your system type, CPU, printer manufacturer/model, and (obviously ;-) paper size. | If it is of any help, psroff also has the ability to convert CAT troff output | to ditroff (Device-independent troff). When this ouput is piped to a version | of tpscript (a ditroff - PostScript converter) modified by our Computer Science | department here the page placement is perfect (but tbl line placements do not | meet perfectly - alas). Has anyone similarly modified psroff for correct page | placement ? The tbl/ditroff problem is, I believe, fixed now, but I'm unable to remember what I did... What exactly is wrong? Corner matching? Did your Computer Science Department modify the width tables for your tpscript? Did you use my width tables or theirs? psroff also can generate HP Laserjet output, and even download fonts (provided you have patch level 7, or Release 2 - real soon now! ;-) -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list