printing problem - spurious characters printed randomly interspersed in printout - since Sarge/kernel update

["Daniel B." <dsb@smart.net>]

Since I upgraded to Debian Sarge and kernel 2.6.8 (2.6.8-2-k7-smp),
I've been getting lots of errors in my printouts.  

The error pattern is that at multiple, seemingly random positions in 
the middle of the printout, there is a spurious "d" character, and 
frequentlyright 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,
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 somtimes 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 Woody and kernel 2.4 to 
- Printing still prints fine from Windows.
- Plain-text documents print fine (lpr xxx.txt), with no known
  errors.

Because plain-text documents (seem to) print file, 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 Sarge and kernel 2.6
_and_ switched from lpr to CUPS.

Thinking the problem was something in CUPS or foomatic (the PPDs 
files?), today I removed CUPS and re-created my previous setup that 
used lpr and magicfilter for printing.  Unfortunately the problem 
still remains (except that plain-text files print fine, since they 
are printed 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 bytes 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 (to see the the errors are being injected before 
that point)?

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

Any other ideas?

 
Thanks.

Daniel
-- 
Daniel Barclay
dsb@smart.net