From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Cc: theoh@chiark.greenend.org.uk Subject: Re: [9fans] psutils et al In-Reply-To: Your message of "Thu, 15 Feb 2001 15:31:00." <20010215142606.4C388199E3@mail.cse.psu.edu> References: <20010215142606.4C388199E3@mail.cse.psu.edu> From: Theo Honohan Message-Id: Date: Thu, 15 Feb 2001 15:30:08 +0000 Topicbox-Message-UUID: 6636535c-eac9-11e9-9e20-41e7f4b1d025 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.