There's a nasty little performance problem on the Epson R2400. Epson
determined that it happens if the starting horizontal position isn't a
multiple of 8 horizontal positions, and I've verified that rounding
the starting position down to a multiple of 8 solves it -- the printer
prints about 10x faster, with no pauses between passes. The issue is
that the printer apparently has to do a lot more work internally. I
suspect that that's not the only printer with this issue.
The problem with the simple solution is that it usually doesn't
position the output precisely where the user requested. The
horizontal error can be between 0 and 7 dot positions. The absolute
amount of this error, of course, depends upon the horizontal
resolution, but at 360 DPI the worst case error is 7/360" (about 1/50"
or 0.5 mm) and the average error is 3/360". At higher resolutions the
error (both worst case and average) is less. At any resolution
greater than 360 DPI (from 720x360 DPI on up), the worst case error is
less than 1 point, which is the unit of precision, but at 360 DPI the
worst case error is greater than 1 point.
The lowest horizontal resolution supported by Gutenprint on Epson
printers is 180 DPI, in which case the worst case error is about 1
mm. I'm not too worried about that because that's an economy draft
resolution that nobody has high expectations for. I'm also not
worried about high resolutions because the error's very small.
Since the horizontal position in question is always non-negative (even
in full bleed mode the absolute horizontal position as specified to
the printer is always non-negative; the actual origin is shifted), I
believe that it's always safe to round the horizontal position down.
The question I have is whether I should try to correct this error.
There are several options:
1) Leave everything as is. The problem is that the printing
performance is REALLY bad; it takes probably 10x as long to print
as it should. This effectively makes the printer useless.
2) Round the starting horizontal position down as described above.
This has the advantage of simplicity (very important, particularly
right now) -- it's one line, and it's easy to test:
*** print-escp2.c.~1.349.~ 2006-04-16 22:08:21.000000000 -0400
--- print-escp2.c 2006-04-29 12:28:27.000000000 -0400
*** 2628,2633 ****
--- 2628,2634 ----
pd->micro_units = horizontal;
pd->horizontal_units = vertical;
+ /* Note hard-coded 1440 -- from Epson manuals */
if (escp2_has_cap(v, MODEL_COMMAND, MODEL_COMMAND_1999) &&
escp2_has_cap(v, MODEL_VARIABLE_DOT, MODEL_VARIABLE_NO))
pd->micro_units = 1440;
*** 2815,2820 ****
--- 2816,2826 ----
pd->image_scaled_width = pd->image_width * pd->res->hres / 72;
pd->image_printed_width = pd->image_width * pd->res->printed_hres / 72;
pd->image_left_position = pd->image_left * pd->micro_units / 72;
+ * Many printers print extremely slowly if the starting position
+ * is not a multiple of 8
+ pd->image_left_position = (pd->image_left_position / 8) * 8;
pd->page_bottom += extra_top + 1;
3) Round the starting horizontal position to the nearest (below or
above) multiple of 8. This reduces the worst case error to 4/360"
(1/90"), or less than one point. The difficulty is that shifting
the image right means that it's necessary to check whether the
image would be shifted off the page, and if so either shift it left
or accept the poor performance. This adds a fair bit of complexity
and a lot more testing.
4) Increase the horizontal resolution as told to the printer (when
printing at 360 DPI tell the printer that it's actually 720 DPI and
then double the spacing between drops). This would reduce the
error correspondingly, and we already have to do this when printing
at 360x240 DPI (720 DPI is the LCM of 360 and 240). It's probably
safe (since the code's already there and it's just one spot), but
some printers could have difficulty.
5) Add dummy data, either at the color level, the dithering level, or
the weave level, to position the output exactly. This breaks the
API (or at least requires a new internal API) and seems very
complicated for what it's doing (there are a lot of places for this
to go wrong -- memory allocation and other fencepost conditions,
My thought is that I should stick with the solution describe above --
round the horizontal position down. It's so much simpler than any
solution other than (4) -- and doesn't run the risk of triggering
other printer firmware issues -- that I think it outweighs the small
loss of printer positioning accuracy. In addition, these printers
seem to have a paper positioning error (repeatability) of at least .5
mm of their own, and we're talking worst case of just about that, and
even that only at draft resolution (printing at 1440x720 DPI, for
example, has a worst case error of about 1/200").
I'm still waiting to hear from Epson about what other printers may be
affected, but this solution seems far and away the best, all things
considered. The problem is bad enough that I really do want to fix
Robert Krawitz <rlk@...>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@...
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."