Re: printing problem - spurious characters printed randomly interspersed in printout - since Sarge/kernel update
Daniel B. wrote:
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?
I haven't seen this but I also have a BJ-series printer and mine has DIP
switches which I used to experiment with different emulation modes and
other settings. I think one emulation mode was Epson compatible, and
the other native.
What might be causing the random variation in the errors?
One guess is that you are using the wrong emulation mode, or the right
emulation with the wrong DIP switch setting. Also I tried different BJ
series .ppd files and I ended up using a .ppd file for a different
model, but never understood why it seemed to work better.
How can I intercept the bytes that are being sent by lpd
You mean cupsd? Are you trying to run both together?
to the
printer device (to see the the errors are being injected before
that point)?
The only way I know to intercept parallel port data is gdb (possibly
with ddd or other front end) or a logic analyzer, but these seem like
massive overkill.
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)?
The simplest way is so swap out the suspect device, but why or how
do you think this could happen?
Any other ideas?
Might be worth trying different parallel port modes (ECP, EPP, etc.) by
reconfiguring the kernel or BIOS. Other than that, you might try to see
if you can track down what changed to cause the problem. If you have
backups and a spare drive, you might be able to repeat the upgrade and
isolate the package upgrade which triggered the problem.
Thanks.
Daniel
Reply to: