Xref: utzoo comp.text:1883 comp.lang.postscript:552
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!gatech!udel!rochester!ken
From: ken@cs.rochester.edu (Ken Yap)
Newsgroups: comp.text,comp.lang.postscript
Subject: Re: want a version of ditroff which generates PostScript directly
Keywords: page description preview
Message-ID: <9625@sol.ARPA>
Date: 12 May 88 07:12:38 GMT
References: <52973@sun.uucp>
Reply-To: ken@cs.rochester.edu (Ken Yap)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 66

|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

What do you mean by more efficient? Less bytes? Surely in this day and
age, it doesn't matter. You don't see the ditroff anyway, it goes into
a pipe or intermediate file, unless you want to preview it.

|	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

Ah, you want to execute less PS procedures then. Trouble is, ditroff's
idea of a word space may not match the width of the current font's space.

|So, does anyone sell and support a `ditroff` which generates PostScript
|directly?  Can anyone explain why ditroff still generates its peculiar
|intermediate form in this day and age?

Because of (1) inertia of history and (2) it is easier to write N
backends for N printer languages than to rewrite ditroff for every
possible printer language. It gives a degree of isolation that allows
flexibility in implementation.  Think of the divergence in ditroff
versions if hackers added #ifdefs for every printer in sight.

|The tragic irony, which I'm almost to ashamed to admit, is that James
|Gosling here at Sun wrote such a modified `ditroff` one afternoon (!!)
|a few years ago, but I couldn't get it to work with our font set and
|then-current version of ditroff.  I saw the future, and it fell away.

Maybe that is why you couldn't get it to work :-). It was a
non-portable approach.

Now for a slightly controversial statement:  It is always easier to
write a code generator to go from a less powerful language to a more
powerful one. It is this that makes writing backends for ditroff
straightforward, in theory, at least.  Ditroff code demands little in
way of printer language support, basically the ability to lay down
characters, move on the printing surface. (Although there are some
complex geometric primitives that often have to be provided in the
backend.) Even so, some output devices give no end of trouble for
backends---I can point you to war stories.

Why not then generate PS and write PS to foo converters?  PS is nice
but I think it is a mistake to design your text formatter to generate a
language whose full power you don't need.  Sooner or later programmers
start to make use of the "nifty" language features and you lose
compatibility with the low end devices.  Assuming you care about
portability. Hence an intermediate language. I agree with this decision
but dislike the language format.

Incidentally, contrary to some belief, ditroff output is not device
independent. It is very device dependent.  It is the program that is
device independent.  It is supposed to be dynamically reconfigurable
for the device you have. Almost. Again, this goes into war stories.

	Ken