Re: [9fans] psutils et al

Re: [9fans] psutils et al

[Theo Honohan]

rog@vitanuova.com wrote:
> > As long as the driver used by
> > page produces images rather than drawing directly in a window, the
> > question of whether it's page or the driver that does the bit
> > manipulation is moot.  (And, if we agree that page should provide the
> > facility of rotating any displayed image, then page might as well do
> > it.)
>
> i think the point is that ghostscript already applies an arbitrary
> transformation matrix when rendering down to the final image that will
> be passed to page so, in this case anyway, it would be vastly more
> efficient to tell ghostscript to render rotated, rather than to rotate
> the resulting image.

Er, yes.  I wasn't very clear: Wouldn't it be cleaner for the
document-relative orientation of the bitmaps produced by the driver to
be consistent, and for successive changes to the orientation of the
page to be handled entirely within "page"?  It seems to me that the
way orientation is handled in gs's X11 driver is slightly messy, but
acceptable as part of the final presentation on the device (and as
part of a system which also allows the user to zoom in).

I don't think it's so easy to justify reusing that solution in the
page/gs architecture, as things stand.  If we were talking about a
standalone ps viewer that rendered straight to the screen, then that
would be different.

I don't think the efficiency case is all that clear cut, either --
pages can take a very long time to render from scratch.

Re: [9fans] psutils et al

[rog]

> As long as the driver used by
> page produces images rather than drawing directly in a window, the
> question of whether it's page or the driver that does the bit
> manipulation is moot.  (And, if we agree that page should provide the
> facility of rotating any displayed image, then page might as well do
> it.)

i think the point is that ghostscript already applies an arbitrary
transformation matrix when rendering down to the final image that will
be passed to page so, in this case anyway, it would be vastly more
efficient to tell ghostscript to render rotated, rather than to rotate
the resulting image.

as page has a fairly close association with ghostscript anyway, this
shouldn't be too difficult.

i guess if you want to view a gif/jpeg rotated, one can rotate it
first.  pity fb/* has gone.

  cheers,
    rog.

Re: [9fans] psutils et al

[rog]

> Er, yes.  I wasn't very clear: Wouldn't it be cleaner for the
> document-relative orientation of the bitmaps produced by the driver to
> be consistent, and for successive changes to the orientation of the
> page to be handled entirely within "page"?

yes.
however...

> I don't think the efficiency case is all that clear cut, either --
> pages can take a very long time to render from scratch.

if you just have page tell ghostscript to render it the right way the
first time (which it can do if it looks at the PageOrientation header)
then it'll take exactly the same time as before. (important if you've
got a whole document in landscape mode)

i hadn't imagined a "flip" option to the page menu, just that it should
get it right first time.  (if the postscript header is wrong, it can
always be inserted manually - but that's an issue for the creator of
the broken postscript, not for page)

  cheers,
    rog.

Re: [9fans] psutils et al

[rog]

> I'm not sure whether managing the display orientation should be part
> of "page"'s job.  Judging from the presence of the "u" option, and by
> analogy with the way I seem to use real photos and sheets of paper,
> I'm inclined to think that it is.

well, it's certainly to do with the presentation end of the process
(given the postscript "%%Orientation: (Portrait|Landscape)" header)
however, i'm somewhat surprised there's not some way of specifying a
page transformation to ghostscript which would avoid the painful
process of doing it via bit manipulation of the displayed image...

from a brief glance at the documentation, a ghostscript driver can
specify an arbitrary transformation between user coords and device
coords, so i imagine it should be possible to tell the plan 9 driver to
rotate the page if the page orientation said so.

  rog.

Re: [9fans] psutils et al

[Theo Honohan]

rog@vitanuova.com wrote:
> > I'm not sure whether managing the display orientation should be part
> > of "page"'s job.  Judging from the presence of the "u" option, and by
> > analogy with the way I seem to use real photos and sheets of paper,
> > I'm inclined to think that it is.
>
> well, it's certainly to do with the presentation end of the process
> (given the postscript "%%Orientation: (Portrait|Landscape)" header)
> however, i'm somewhat surprised there's not some way of specifying a
> page transformation to ghostscript which would avoid the painful
> process of doing it via bit manipulation of the displayed image...

It is perhaps surprising that there isn't a general mechanism.  On the
other hand, it is a driver-specific issue, which is addressed
adequately for the X11 case, at least.  As long as the driver used by
page produces images rather than drawing directly in a window, the
question of whether it's page or the driver that does the bit
manipulation is moot.  (And, if we agree that page should provide the
facility of rotating any displayed image, then page might as well do
it.)

>
> from a brief glance at the documentation, a ghostscript driver can
> specify an arbitrary transformation between user coords and device
> coords, so i imagine it should be possible to tell the plan 9 driver to
> rotate the page if the page orientation said so.

Yes, at the very least.

Re: [9fans] psutils et al

[Theo Honohan]

nemo@gsyc.escet.urjc.es wrote:
>
> 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 fact, the standard X11 viewers (ghostview and, much better, GV)
change the orientation of the display by setting the GHOSTVIEW
environment variable.  gs's X11 display driver reads a number of
configuration options from the value of GHOSTVIEW before drawing.
(see gdevxini.c)

I don't think trying to change the orientation with a ps prologue
will be reliable in all cases.  mpage does a good job, but it has
its shortcomings:

http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=25170


> In any case, I'd say that's  the job of a filter and not of
> page.

It's clear that we should be able to control the orientation in which
the page is displayed independently of the internal coordinate
system and transformation matrix used by the postscript interpreter.

I'm not sure whether managing the display orientation should be part
of "page"'s job.  Judging from the presence of the "u" option, and by
analogy with the way I seem to use real photos and sheets of paper,
I'm inclined to think that it is.

Theo

[9fans] psutils et al

[nemo]

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.

Re: [9fans] psutils et al

[geoff]

I have a cleaned-up mpage running on Plan 9.  Dave and Russ, what's
needed to get this out to the world?