[9fans] Re: psutils et al

[9fans] Re: psutils et al

[John A. Murdie]

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

Re: [9fans] Re: psutils et al

[Douglas A. Gwyn]

"John A. Murdie" wrote:
> ... On Unix and Plan 9, I'd say that was probably
> at the ditroff output level. ...

Unfortunately, troff "knows" physical characteristics of the
device when it preforms the formatting.  Certainly, ditroff
output can be manipulated by filters and device interpreters
(e.g. there is often a "landscape" switch), but the language
is a little too close to the hardware to expect good results.

Re: [9fans] Re: psutils et al

[Douglas A. Gwyn]

"Douglas A. Gwyn" wrote:
> preforms

Yes, it should have been "performs".
zzzzz

Re: [9fans] Re: psutils et al

[Douglas A. Gwyn]

"John A. Murdie" wrote:
> Thanks, this is interesting. So, if I am writing an application
> program for Plan 9 which requires to print graphical output,
> what document description language do I use? I think I'd probably
> write pic/eqn/tbl etc. Is that your solution too?

Yes, indeed there are other preprocessors such as chem, grap, dot,
etc. that produce pic-language output (and sometimes other formats).
Pic makes a fairly good diagram description language.

> Where then should one do any N-upping, page rotation etc that is
> required, ...

There should be no problem using PostScript-oriented tools so long
as you have decent (Adobe document structure conforming) Postscript
files, which can be produced from ditroff among other things.  What
I think people were complaining about was (1) they don't have good
ports of decent PostScript tools, and (2) some pre-existing
PostScript files, for example those produced by some methods of
using Microsoft Office applications, are badly formatted.  But (2)
should not be an issue when you have control over the generation
of the original PostScript files.

> What should the Plan 9 solution be?

Presumably make some sort of file system :-)

[9fans] Re: psutils et al

[John A. Murdie]

"Douglas A. Gwyn" <gwyn@arl.army.mil> wrote:
>"John A. Murdie" wrote:
>> ... On Unix and Plan 9, I'd say that was probably
>> at the ditroff output level. ...
>
>Unfortunately, troff "knows" physical characteristics of the
>device when it preforms the formatting.  Certainly, ditroff
>output can be manipulated by filters and device interpreters
>(e.g. there is often a "landscape" switch), but the language
>is a little too close to the hardware to expect good results.

Thanks, this is interesting. So, if I am writing an application
program for Plan 9 which requires to print graphical output,
what document description language do I use? I think I'd probably
write pic/eqn/tbl etc. Is that your solution too? Where then
should one do any N-upping, page rotation etc that is required,
given that doing it at the PostScript level invites people similarly
to post-process bad PostScript? What should the Plan 9 solution be?

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

[9fans] Re: psutils et al

[John A. Murdie]

"Douglas A. Gwyn" <gwyn@arl.army.mil> wrote:
>"John A. Murdie" wrote:
>> ... On Unix and Plan 9, I'd say that was probably
>> at the ditroff output level. ...
>
>Unfortunately, troff "knows" physical characteristics of the
>device when it preforms the formatting.  Certainly, ditroff
>output can be manipulated by filters and device interpreters
>(e.g. there is often a "landscape" switch), but the language
>is a little too close to the hardware to expect good results.

Thanks, this is interesting. So, if I am writing an application
program for Plan 9 which requires to produce graphical output,
what document description language do I use? I think I'd probably
write pic/eqn/tbl etc. Is that your solution too? Where then
should one do any N-upping, page rotation etc that is required,
given that doing it at the PostScript level invites people similarly
to post-process bad PostScript? What should the Plan 9 solution be?

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

Re: [9fans] Re: psutils et al

[nemo]

:  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.

The problem is when you got some ps from powerpoint and you don't
have to use it. Although I try hard not to fall into it, this time
I had to do it. So, although it may not be the right way, I think it's
still useful to be able to do such kind of things to the postscript.

Re: [9fans] Re: psutils et al

[nemo]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

:  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.

I'm sorry. I didn't want to say that the author did a bad job,
I was only trying to say that it was mpage the one who did the job for
me.


[-- Attachment #2: Type: message/rfc822, Size: 4011 bytes --]

From: "John A. Murdie" <john@cs.york.ac.uk>
To: 9fans@cse.psu.edu, john@cs.york.ac.uk
Subject: [9fans] Re: psutils et al
Date: Thu, 15 Feb 2001 09:43:35 +0000
Message-ID: <E14TKx9-0002eE-00@minster.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

[9fans] Re: psutils et al

[John A. Murdie]

nemo@gsyc.escet.urjc.es wrote:
>:john@cs.york.ac.uk wrote
>:  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.
>
>I'm sorry. I didn't want to say that the author did a bad job,
>I was only trying to say that it was mpage the one who did the job for
>me.

No need to be sorry; I didn't take what you said that way. I'm
surprised that mpage worked for you; as far as I know its approach
is effectively the same as that of psnup, which is inadequate with
non-DSC PostScript. I stand by my view that PostScript is not
suitable for generic postprocessing.

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

[9fans] Re: psutils et al

[John A. Murdie]

I wrote:
>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.

Oops, typo - I meant `GDI' not `DGI', of course.

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