[Printing-user-general] printing problem - spurious characters printed randomly interspersed in printout - since gs, kernel update

I've been getting lots of errors in my printouts since I upgraded to
the Sarge version of Debian GNU/Linux and to the Linux kernel 2.6.8
(Debian version 2.6.8-2-k7-smp).

The error pattern is that at multiple, seemingly random positions in
the middle of the printout, there is a spurious "d" character, and
frequently right after the "d" there sometimes is a column or two of
erroneous dots.  (Sometimes after the "d" the printer jumps to the
next page; sometimes the printer beeps a lot as if it is rendering
ASCII BEL characters.)

The printed "d" seems to be in the printer's native font for plain-
ASCII(+) printing.  (It's not in the same Postscript font of any text
in the middle of which the error occurs.)

This applies to files that go through the magicfilter/gs rasterizer
(and applied with I tried CUPS), but does not seem to apply to text
files (which get written directly to the printer).

It seems as if:

- the (non-Postscript) printer (a Canon BubbleJet BJ-200ex) had
   correctly executed a printer command to print out a packet of the
   bitmap generated by magicfilter, magicfilter's bj200 filter, and/or
   gs (gs-gpl)

- the printer was ready for another character (to print plainly) or
   bitmap printing command

- something got out of sync between the stream of printer commands
   from the rasterizer and the printer itself

- the next byte in the stream was an ASCII "d" (a 0x64 byte),

- the printer, being back in plain-text mode, printed a "d"

- the printer recognized a bitmap-printing command, and got back
   into bitmap-printing mode, but something wasn't quite synchronized
   (thus the the next column or so of dots got messed up)

- things got synchronized again for a while (since the printout's fine
   for sometimes several printer lines' worth of bitmap dots until the
   next error).

The location of the errors seems to be random.  Re-printing the same
document the same way (e.g., printing a text document through enscript
or printing a web page from a browser) yields errors in different
locations.

It does not seem to be a cabling or printer unreliability problem:
- I haven't even unplugged the printer or printer cable (parallel)
   since I upgraded from Debian Woody and kernel Linux 2.4 to Debian
   Sarge and kernel 2.6.
- Printing still works fine from Windows.
- Plain-text documents print fine (lpr xxx.txt), with no known
   errors.

Because plain-text documents (seem to) print fine, it doesn't seem
to be a kernel problem with the parallel port.

Therefore, it seems to be a printing software problem--except that
the randomness (the non-repeating position and the varying quantity
of the errors) doesn't make sense.



I first noticed this problem when I upgraded to Debian Sarge and Linux
kernel 2.6 _and_ switched from lpr to CUPS.

Thinking the problem was something in CUPS or foomatic (the PPD
files?), I removed CUPS and re-created my previous setup that used lpr
and magicfilter for printing (as far as I could--that is, with Debian
Sarge versions of, say, gs and with kernel 2.6).  Unfortunately the
problem still remains (except that plain-text files now print fine,
since with my lpr/magicfilter setup they go more directly to the
printer).

The errors always involve a "d" character.  That makes me think that
the "d" characters I see are 0x64 bytes that were supposed to be part
of the frame around bitmap data, and that some count of bitmap-data
bytes is getting out of sync with the stream of bitmap-data bytes
(e.g., as if an extra byte or bytes, or a bad count, is being
generated by the Postscript-to-bitmap renderer or an extra byte or
bytes are being written out to the printer).


Has anyone seen a problem like this?

What might be causing the random variation in the errors?

How can I intercept the bytes that are being sent by lpd to the
printer device (/dev/lp0) (to see the the errors are being injected
before that point)?

Would pointing lpd to a pipe (or maybe even a file) instead of
/dev/lp0 work?  Does lpd do anything with ioctls such that it would
fail or refuse to work with a device file that's not a character
device?  (In that case, is there any way to log the data that's
written to a character device?)

How can I check the bytes that are actually being send out from
the kernel to the parallel port (to see if the errors are being
injected after the byte stream gets to the parallel port device
(/dev/lp0))?

The reason I'm thinking about intercepting the data at different
points is to see if I can find where the randomness first shows up.
For example, if it first shows up in the output of the gs filter,
then pretty surely gs is buggy; if it doesn't show up in the data
written into the kernel by lpd at /dev/lp0, then the problem's
not in gs, lpr, or CUPS but is in the kernel or beyond; etc.

Any other ideas?


Thanks.

Daniel
-- 
Daniel Barclay
[email protected]