[cups-devel] Crash in rastertoepson.c

Wed Mar 25 20:43:40 PDT 2015

Michael,

Thanks for the response.

I'll clean up my quick hacks and debugging code soonish.  Probably
next week or the week after, unless configuration stuff (below)
takes longer...

Do you have a preferred strategy for working around things like
my ALPS firmware bug (triggered by shingling)?  Some possible
options include:

1. Unconditionally disable shingling for most modes (resolutions).
   Print alternating pixels in two passes without advancing
   the print head in between (by 1/3 or 2/3 head height).  The
   non-shingling code path is mostly ready to do this already,
   with just a few tweaks...

       But I thought of one way that shingling might be
   useful, and so it might not be desirable to disable it
   by default.  Specifically, the shingling may reduce visual
   banding [white horizontal lines] if something like a fold
   in tractor-fed printer paper causes the paper to be slighly
   misaligned compared to where the feed mechanism tries to
   put it.

2. Something really simple to code up a check, like an environment
   variable such as ("CUPS_RASTERTOEPSON_DISABLE_SHINGLING=1").

       But knowing about and changing this setting is not user
   friendly.  And it would probably apply globally to all
   printers.

3. Somehow add an advanced setting for disabling shingling in
   the administration UI.  Probably the "best" option.
   A variation on this idea is to specify it in the .ppd only
   (no user setting), but then someone with this problem can't
   just use the built-in generic epson driver?

       But I'm not sure exactly what is involved in adding a new
   setting for a printer.  Any recommendations on where to look?
   Something in the PPD?  Something in some kind of input used
   to generate the PPD?  How to read the setting from withing
   rastertoepson.c?  Other section(s) of code?

Barring other direction, I'll probably start with something simple
like an environment variable, and later revise it based on feedback
(unless someone else volunteers to replace the environment variable
part)...

                        - Matthew

On Wed, Mar 25, 2015 at 07:01:08AM -0400, Michael Sweet wrote:
> Matthew,
> 
> Sorry for the late reply (was on vacation) but please do submit your changes and we'll incorporate them into CUPS.  In parallel I'll make sure we don't have any other issues with odd-numbered widths.
> 
> (the output issues with the 980 should be reported to the Gutenprint folks separately...)
> 
> > On Mar 7, 2015, at 10:53 PM, Matthew Ogilvie <mmogilvi_cups at miniinfo.net> wrote:
> > 
> > rastertoepson.c will crash near line 658 if header->cupsWidth
> > is an odd number, because "width" is unsigned and when it is always
> > decremented by 2, an odd number will never become less than 1.
> > 
> >>       for (width = header->cupsWidth, tempptr = CompBuffer;
> >>            width > 0;
> >>            width -= 2, tempptr += 2, oddptr += DotBytes * 2,
> >>                evenptr += DotBytes * 2)
> > 
> > I saw this when trying to print IRS form 8889 using
> > evince 3.12.2, when I configured cups with a generic
> > Epson 24 pin dot matrix printer, and ask to print it
> > with a resolution of either 360x180 or 180x180.  The
> > crash probably became reliable as of commit
> > 7e86f2f686334cb3db458b4585dfce9c1b712bc4 in Feb 2014,
> > when several variables were changed to unsigned.  But I'm not
> > sure if the code correctly handled the odd-number width case
> > before that: it might have had a buffer overflow that was
> > rarely apparent - one instead of infinite.
> > 
> > Another problem: Although it isn't hit in the same configuration,
> > there might be a problem in the interleave case of OuptutRow()
> > as well: if the quantitiy (dot_count/DotBytes) happens to be
> > odd, then it will be one byte short outputing characters to
> > the printer in each case, interpreting the next byte (often "\033")
> > as part of the bitmap data.  I'm uncertain if this happens
> > in practice, or only in theory.
> > 
> > --------------
> > 
> > Working around firmware bug:
> > 
> > Slight tangent: I specifically have an old "ALPS 324e" dot
> > matrix printer, and it isn't printing shingled data
> > from this driver correctly even when the above is avoided.
> > (other document, or a minimally hacked driver):  It will
> > generates a vertically doubled/blurry image that is very
> > ugly (off by about 3 or 4 pixels).
> > 
> > After carefully auditing the middle-of-the-image shingling
> > logic [looks good, at least ignoring if boundary conditions],
> > examing the input raster data fed into rastertoepson [looks
> > good], and directly sending the printer hand-crafted test
> > patterns [without cups at all], it looks like the printer
> > has some kind of firmware bug that causes it to advance
> > the page an incorrect amount when the newline advance is
> > set to less than 24/180 of an inch AND other conditions theat I
> > haven't fully characterized involving dataless blank lines
> > are met.  These bad conditions happen to be met for every
> > pair of lines when the driver is doing the shingling thing.
> > 
> > If I hack the driver to avoid shingling in the 180x180 and
> > 360x180 cases (and instead rely on a slightly tweaked version
> > of the "interleave" case in OutputRows()), then it seems to
> > work MUCH better.  When properly driven, the printer's output
> > is fairly hard to tell is from a dot matrix printer.
> > 
> > QUESTION: If I submitted a cleaned up version of my hack to
> > disable shingling in the 180x180 and 360x180 cases, is there
> > any chance it would be accepted?  Or is there some reason
> > to prefer the shingling operation for other printers that
> > I'm just not seeing?
> > 
> > As near as I can tell, the shingling is useless in these
> > cases.  It usually isn't any faster than interleaving, and at
> > least in my buggy firmware case, the interleaving is a much
> > more robust way to handle printer limitations with consecutive
> > pixels.  I'm not sure about the 360x360 case: This printer's
> > documentation doesn't seem to claim any way to support it,
> > I'm not sure how it is supposed to work, and I would probably
> > leave it as-is.
> > 
> > --------------
> > 
> > Farther-off tangent: I also have an "Epson Stylus Color 980 N"
> > inkjet printer.  I think it uses a driver from gutenprint instead
> > of cup's rastertoepson, although I haven't dug into the details yet.
> > 
> > But the interesting thing is that its output (when driven from
> > cups+gutentprint) has always been doubled/blurry in a way that
> > is very similar to the ALPS printer (a few pixels off vertically).
> > It seems odd that two completely different printers with (presumably)
> > different drivers would look as similar as these do.
> > 
> > When driven from a much older machine (using another driver
> > framework not related to cups+gutenprint at all), both the
> > Epson and the ALPS look much better.
> > 
> > History trivia: The inkjet uglyness thing has long been an
> > annoyance, but I mostly just lived with it because I only
> > rarely need to print anything.  But then its ink ran/dried out yet
> > again, and when I finally tried to switch back to the ALPS, I
> > ran into both a similar problem and a crash, and decided to spend
> > a little time digging into it...
> > 
> > --
> > Matthew Ogilvie
> > _______________________________________________
> > cups-devel mailing list
> > cups-devel at cups.org
> > https://www.cups.org/mailman/listinfo/cups-devel
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> 