[cups.bugs] imageablearea malfuction...

Jeff Wiegley jeffw at csun.edu
Fri Oct 15 17:47:15 PDT 2004


I submitted a bug on this but Mr. Sweet shot it down
and closed it. (But I still believe it's a bug so I'll
try to get it worked out here.)

You may refer to: http://www.cups.org/str.php?L962 for
the original bug submission.

Mr. Sweet's position on the subject:
"The imageable area defines the size and position of the page
image; by altering the imageable area outside the area supported
by the printer, the image is shifted by the printer."

Well... it's still a bug because... even if I set the
imageablearea *inside* the area supported by the printer
the image gets shifted.  The response I got led me to
believe that not enough time was taken to understand the
problem I submitted. I'ld still love to hear a rational
reason as to why a cropping boundary moves image content. 

here's some specifics:
I created a *really* simple 1/8 inch labeled grid in postscript:
%!PS-Adobe-3.0

/Times-Roman findfont 12 scalefont setfont -72 -72 translate
gsave
%% print horizontal lines
108 { 0 0 moveto 756 0 lineto stroke 144 0 moveto 0 9 translate} repeat
grestore gsave
%% print vertical lines
84 { 0 0 moveto 0 972 lineto stroke 0 144 moveto 9 0 translate} repeat
grestore gsave
%% print vertical tick marks
(B) (A) (9) (8) (7) (6) (5) (4) (3) (2) (1) (0)
0 72 translate
12 { 378 0 moveto show 0 72 translate } repeat
grestore
%% print horizontal tick marks
(8) (7) (6) (5) (4) (3) (2) (1) (0)
72 0 translate
9 { 0 486 moveto show 72 0 translate } repeat
showpage

The (X) letters are printed on inch lines so I can tell where
that particular line *should* have shown up. (1) should appear
on a line printed 1 inch from the bottom of the page and also
on a line printed 1 inch from the left edge of the page.

The grid extends beyond all page boundaries 1 inch. On a printer
without limitations the intersection of (0,0) should print in the
very lower left corner.

My printer has limitations. In fact it is specifically a
Hewlett Packard 3330MFP. I have used the laserjet.ppd
setting.

Now let's say I set an imageablearea of:
   *ImageableArea Letter/US Letter:	"144 144 540 720"
which I have done. This is a page with a left and bottom
margin of 2 inches and a top and right margin of 1 inch.

Now I print my grid. Let's talk about the Y (vertical) direction
first in an attempt to prove I'm not crazy...

The first visible line seen is the grid line marked 2 because
lower 3 inches of the grid should be masked by the imageablearea
cropping boundary. It appears exactly as it should. Also the
top margin is a blank 1 inch as expected. I see 8 inches of
visible grid starting 2 inches from the bottom of the page and
the lowest visible line is marked "2". So the vertical direction
works fine.

But let's think about the X (horizontal) axis for a moment.
The first visible grid line should also be "2" and it should
print 2 inches in from the left margin. I should also see
5.5 inches of visible grid lines with a 1 inch right margin.

This is NOT what I see printed though.
What I do see is the correct visual information but it is
left justified (almost). The first visible line is marked
"2" but it appears 0.25 inches in from the left margin.
Also strange is that, not only did it disturb the left
imageablearea setting, but it also affected the right
imageablearea setting, that is to say I wound up with a
2.75 inche right margin.

This is just plain wrong, wrong, wrong.
A cropping boundary *should* crop; it should *not* move
content. Otherwise, intelligent publishing tools are
affected. For instance my LaTeX document expects to
produce a 0.75in left margin. Xdvi, acroreader and
gs all show correct output when the output device is
the X-window but when it prints CUPS messes with
content position.

Please specifically note that Mr. Sweet said the *printer*
shifts my image because I gave it data outside of it's
imageable area. Well the imageablearea setting given
in this example is well within even the worst printer's
imageable area. It is *not* the printer doing the shifting.
*CUPS* is doing the shifting. (As additional evidence of
this: I can send raw postscript data to this printer that
is way outside of a page boundary and it doesn't shift
anything. It simply prints what it can.)
Or possibly Ghostscript is shifting the image but if it
is doing so then my guess is it is doing it because CUPS
told it to.

Also: If I send the grid.ps file to the printer
through a raw device the printer crops small portions
as it should (because it does have some area that it
cannot print to.) But the portion it crops is less than
the default CUPS ppd file does. If I measure it and stick
the values into the imageablearea setting I get crap
because the vertical direction conforms to my measurements
while the horizontal direction *forces* a left non-printable
area exactly 0.25 inches wide and shifts the content to
justify it with that. (my actual non-printable area on the
left side is 5/32 of an inch.)

Am I missing something super basic here? I don't think
so. I postulate that something is very wrong with the
horizontal imageablearea calculations. Please help me
fix it.

Thanks,

Jeff Wiegley





More information about the cups mailing list