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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
