spage%polar@Sun.COM (S Page Sun Mtn View windows writer/engineer 691-2410) (05/12/88)
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
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?
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.
These are my opinions, not my employer's; NeWS and PostScript and maybe
even `ditroff` are TMs of their various owners.
Thanks in advance for any pointers or information,
=S Page Tech Pubs (windows) spage@sun.COM (415)691-2410 M/S 14-40
{hplabs,ucbvax,decwrl}!sun!spageken@cs.rochester.edu (Ken Yap) (05/12/88)
|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
romwa@gpu.utcs.toronto.edu (Mark Dornfeld) (05/13/88)
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
wnp@killer.UUCP (Wolf Paul) (05/14/88)
In article <52973@sun.uucp> spage@polar.UUCP writes: > > Can anyone explain why ditroff still generates its peculiar >intermediate form in this day and age? > Because otherwise it would not be "Device-Independent" troff, but "PostScript-Dependent", i.e. psdtroff. All the efforts of Adobe, Apple, Sun, notwithstanding, there are a lot of output devices out there which do not support PostScript, and a lot of users who do not want to have PostScript - certainly not as the exclusive printer protocol. PostScript is not the most efficient way to format lengthy documents. -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: ihnp4!killer!dcs!wnp ESL: 62832882 INTERNET: wnp@DESEES.DAS.NET or wnp@dcs.UUCP TLX: 910-280-0585 EES PLANO UD
bowen@sunybcs.UUCP (Devon E Bowen) (05/14/88)
In article <52973@sun.uucp> spage%polar@Sun.COM (S Page Sun Mtn View windows writer/engineer 691-2410) writes: >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 The problem here is that you're ignoring a major part of the formatting that ditroff is doing for you. Ditroff output formats each letter individualy so that all the white space that would normally be at the end of the line is evenly distributed between all the letters. Devps (and, I assume, psdit as well) formats as in your example above by soaking up the space between entire words and leaving the between char spacing as the default. In extreme cases, this can look very bad. What your suggesting totally eliminates all of the spacing that ditroff is doing and assumes the default for everything. Since the spacing between characters is set in the dictionaries, this would result in the large block of white space at the end of the line (which is the whole reason you used ditroff in the first place!). We've written (ok, we're putting the finishing touches on) a driver that doesn't eliminate this spacing data anywhere. It formats documents the way ditroff intended them to be formatted. There is no way to make the Post- Script output smaller than the intermediate filter (unless you cheat like devps does) - believe me I've tried! But our filter generates code only about 20% larger. Devon Bowen (KA2NRC) University at Buffalo ********************************************************* uucp: ..!{ames,boulder,decvax,rutgers}!sunybcs!bowen Internet: bowen@cs.Buffalo.EDU BITNET: bowen@sunybcs.BITNET *********************************************************
ron@topaz.rutgers.edu (Ron Natalie) (05/22/88)
> Can anyone explain why ditroff still generates its peculiar > intermediate form in this day and age? D=device I=independant. That's why. Not every printer understands PostScript and vary few typesetters actually do. -Ron