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