Xref: utzoo comp.text:1882 comp.lang.postscript:551 Checksum: 52625 Path: utzoo!utgpu!romwa From: romwa@gpu.utcs.toronto.edu (Mark Dornfeld) Date: Fri, 13-May-88 15:01:17 EDT Message-ID: <1988May13.150117.27392@gpu.utcs.toronto.edu> Organization: University of Toronto Computing Services Newsgroups: comp.text,comp.lang.postscript Subject: Re: want a version of ditroff which generates PostScript directly References: <52973@sun.uucp> Reply-To: romwa@gpu.utcs.UUCP (Mark Dornfeld) Keywords: page description preview In article <52973@sun.uucp> spage%polar@Sun.COM (S Page Sun Mtn View windows writer/engineer 691-2410) writes: >Here at Sun all our printers speak PostScript, and using NeWS we can >preview PostScript directly on-screen. So, why bother producing >ditroff typesetter output files which we immediately turn into >PostScript using `devps` or TranScript's `psdit`? > >Even going through the translation into ditroff intermediate format, >the PostScript file produced by `psdit` is much smaller than the >intermediate file generated by `ditroff` (169K vs 224K for a 38-page >manual). I assume that by going directly to PostScript from within >`ditroff`, you could generate much more efficient PostScript, e.g. >replacing > 288 5253(This)N > 467(publication)X > 887(is)X > 968(protected)X > 1318(by)X > 1428(Federal)X > 1714(Copyright)X > 2094(Law,)X >with > 288 5253(This publication is protected by Federal Copyright Law,)show I thought the "di" in ditroff stood for "device independent". This means that output devices must be handled with post-processors. I doubt if I would consider using troff if it were no longer device independent, since the same program must prepare text for Compugraphic and Postscript devices, not to mention the HP Laser jet in the next room. Mark T. Dornfeld Royal Ontario Museum 100 Queens Park Toronto, Ontario, CANADA M5S 2C6 mark@utgpu!rom - or - romwa@utgpu