This is an attempt to analyze alternative coordinate systems for stapling
and finishing in general. We've found this topic to be very difficult to
discuss even together in person around a white board, so we're concerned
that it may not communicate well in writing, but we'll sure try.
We understand the purpose of the desired coordinate system to be primarily
to support a device management interface, to communicate the capabilities
of the device to a device driver or manager. We understand that the
purpose is not per se to specify stapling/finishing coordinates for
individual documents, although we expect that it would be useful to have
the same or clearly related systems for these purposes.
We have identified essentially three plausible candidate coordinate
systems. Just to give them names here, we'll call them (1) paper-path
centric, (2) "optimized," and (3) media-centric.
The first system, paper-path centric, is pretty easy to describe: Viewing
the paper from the front, i.e. the side from which the staple is pushed,
consider north to be in the paper feed direction. Then the edges (say for
edge stapling) are naturally identified as north, south, east, and west,
the corners as north-west, north-east, south-west, and south-east. Voila.
About this paper-path centric system, we do like that it is easy to
describe and (we think) unambiguous. We dislike that it unhelpfully
distinguishes between printers which happen to mark the left edge of a
portrait page first (in which case the usual corner staple position would
be north-east in this system) vs. those which happen to mark the right edge
first (usual staple position south-west), and forces the driver and system
administrator to be cognizant of and sort this out. We're not sure how
hard this is, it might even make it impossible to write a reliable generic
driver(?).
To try to resolve the unhelpful distinction made by the paper-path centric
system, we would offer the following "optimized" coordinate system. There
are numerous ways to arrive at and describe this system, but here's one:
If the printer marks the left edge of a portrait, long-edge-feed page
first, then the "optimized" coordinate system is defined to be the same as
the paper-path centric; if the printer marks the right edge first, then the
"optimized" coordinate system is defined with north being *opposite* the
paper-feed direction. (In practice this definition may need to be adjusted
to be in terms of short-edge-feed pages, given that there are printers in
the world which only do short-edge-feed.) In the typical single-stapler
configuration, this is equivalent to flipping the coordinate system if the
stapler is on the leading edge vs. the trailing edge of the paper.
About this "optimized" coordinate system, we like that it spares the driver
and administrator from having to know and factor in whether the printer
happens to mark left or right edge first. We sure don't like that it's not
so easy to define or understand.
In the FIN meeting in December, we understood Harry Lewis to advocate a
"document-centric" coordinate system. However, in retrospect, we think
this doesn't quite work, because, for the stated purposes, there is no
document in the picture. We'd be interested in hearing Harry's current view.
The nearest scheme to document-centric which we can find to work is
media-centric, or, more precisely, media-size-centric: For each possible
medium size, let north be in (say) the +x or paper-feed direction, and go
from there. However, this results in a table as long as the number of
media, which seems undesirable. However again, analysis of this table
shows only two significantly distinct cases - short and long-edge feed -
which, when fully optimized, again yields the "optimized" coordinate system
described above (demonstration available on request!).
If we were choosing a coordinate system, we'd choose from between the
paper-path centric system and the "optimized" system. In addition to the
considerations mentioned above, we expect there may be significant other
factors, particularly consistency of model and operation with the rest of
the Finishing MIB, the Printer MIB, and the other relevant print standards
and interfaces, including PostScript and PCL.
We hope this contributes to your party in Hawaii,
Gary Padlipsky & Paul Gloger