[gs-devel] LeadingEdge (was TrayOrientation) patch

[Raph Levien]

Based on feedback from the last version of this patch (which was named
"TrayOrientation"), I have a new version which attempts to be more
compatible with the PostScript setpagedevice standard. The attached
patch is intended to apply against head gs, but it should be
straightforward to merge into GhostPCL.

A few notes on the patch, as some of the internal logic is tricky.

>From the point of view of the PostScript language runtime, LeadingEdge
is designed to be invisible unless it is actually set with
setpagedevice. Most devices should now accept <</LeadingEdge 1>>
setpagedevice as a directive to rotate the raster file generated,
unless this rotation behavior is explicitly overridden in the device.
In my documentation patch, I explain how to write the device so that
it can either simply overwrite the LeadingEdge field in the device
structure, or to let the manual setting take priority.

I had to add a few patches to gs_setpd to tweak the behavior of
/LeadingEdge. For one, the default is for the various parameters used
in tray matching (.inputattrkeys) to _not_ be sent to the device. I'm
not sure why this is. It doesn't seem to me that sending MediaColor to
the device would be actually harmful. In any case, my patch minimally
changes the existing behavior. There's already an exception for
passing PageSize to the device, and I just open that hole a bit more
to allow /LeadingEdge. Incidentally, that patch was proposed in bug
687904. Applying the attached patch should close that bug.

I've also added LeadingEdge to the list of parameters that can be
dynamically changed by the device. That is only important when you
have _both_ manual setting and device overriding, but when this does
happen the new behavior seems to match the PostScript spec.

It's not obvious from reading the various PostScript docs whether
LeadingEdge is used as part of the input matching criteria. The PLRM3
only specifies it as a page device parameter, not an entry in
/InputAttributes. The 3010 and 3011 supplement states that it is used
as part of setpagedevice matching, and that seems to be consistent
with the existing behavior (/LeadingEdge is present in
.inputattrkeys). I did not change that behavior, nor did I implement
any automagical setting of LeadingEdge when it is present in the
/InputAttributes dictionary. It seems to me that having primary
responsibility for setting it in the device rather than in the
PostScript runtime is both simpler and more consistent across
languages.

In fact, even though there's a lot of setpagedevice logic in this
patch, it should also work very well with the PCL (and other)
interpreters. The interpreter just has to send down %MediaSource
explicitly (as in set_paper_source in pcpage.c), and then the device
uses that information to set LeadingEdge from within its put_params.
We then handle the rotation of the page size and bitmap contents
transparently.

I used one int for LeadingEdge, in the same location as
TrayOrientation, because I think there are some devices in our source
tree which use the bad habit of not using the standard macros to
create the device structure. Thus, I use masks to cram both the value
and the "have I been set" boolean flag into the same int, to avoid
changing the number or order of the fields in gs_device_s.

The actual computation of rotated page sizes (gsdevice.c) and initial
matrix (gdevdflt.c) is the same as from the original TrayOrientation
patch, with of course the parameter renamed and the value now in units
of quadrants rather than degrees.

Raph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: leadingedge-patch
Type: application/octet-stream
Size: 22549 bytes
Desc: not available
Url : http://ghostscript.com/pipermail/gs-devel/attachments/20060406/f8097f40/leadingedge-patch-0002.obj