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