[9fans] Re: psutils et al

["John A. Murdie" <john@cs.york.ac.uk>]

nemo@gsyc.escet.urjc.es wrote:
>Yep. I knew them, but almost all of them I tried in Linux either
>did not work as they said, or broke the postscript. Nevertheless,
>mpage -1 -l worked fine in linux. Perhaps it's time to consider a
>port of mpage to Plan9, since my problem was that I was
>unable to do this under plan9.
>
>I read the gs documentation and seems that viewers that
>do the rotate thing are using postscript routines to change
>the page orientation, so I think that unless page could go the
>same way, there is no simple gs option to rotate the ps.
>In any case, I'd say that's  the job of a filter and not of
>page.
>
>hth to others with the same problem.

The psutils are fine; it's usually bad PostScript that causes
them to go wrong. Their manual pages emphasise that they will
only cope with Document Structure Convention -conforming PostScript
(see Appendix G of the second edition of the PostScript LRM; this
appendix has been taken out of the current third edition). This
means much more than their having all the correct DSC pseudo
PostScript comments, by the way; a common misbelief. It's
not really the psutils author's fault that the psutils would
require to use a PostScript program analyser to detect bad input,
and even more effort to process non-conforming PostScript correctly.
He had the option of doing nothing, or making the best of a bad
job and writing something that worked most of the time.

The major offender providing bad PostScript is, in my experience,
- yes, you've guessed it - Microsoft. I spend many minutes a
week dealing with badly generated PostScript from various sources.
If anyone wants me to explain how to fix Microsoft PostScript to
be DSC compatible, ask. At various times I've attempted to write
an rc/awk script to do the job automatically, but it's just too messy.

I'm sad to see these consequences of bad design decisions attempting
to invade Plan 9. (I hope and believe the Plan 9 devotees won't let it
happen.) PostScript is too low a level to be carrying out *everyday*
page transformations; it's just too flexible a language. I think
that such page transformations should be done at a higher level of
document description. On Unix and Plan 9, I'd say that was probably
at the ditroff output level. ditnup, ditselect, dittodit etc, anyone?
In one way, Microsoft had the right idea (if not the right implementation)
with their device-independent DGI page description interface, though
the recent GDI Plus has made this more complex.

John A. Murdie
Department of Computer Science
University of York
England