Re: printing problem - spurious characters printed randomly interspersed in printout - since Sarge/kernel update
Marty wrote:
Daniel B. wrote:
[With] Debian Sarge and kernel 2.6.8 ... I've been getting lots of
>> errors in my printouts. ... at multiple, seemingly random positions
>> ... there is a spurious "d" character...
...
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 ... something got out of sync between the stream of
>> printer commands from the rasterizer and the printer itself
>> ...
Re-printing the same document the same way ... yields errors in
>> different locations.
>>
It does not seem to be a cabling or printer unreliability problem:
>> ...
Because plain-text documents (seem to) print fi[n]e, 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 ... doesn't make sense.
I first noticed this problem when I upgraded to Sarge and kernel 2.6
_and_ switched from lpr to CUPS.
>> ...
I removed CUPS and re-created my previous setup that used lpr and
>> magicfilter for printing. Unfortunately the problem still remains ...
>>
... [I suspect] that the "d" characters ... were supposed to be part
of the frame around bitmap data ... as if [extra 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.
I doubt having wrong dip-switch settings is the problem since it worked
fine with Woody, kernel 2.4, and lpr/magicfilter/gs, and it still works
fine under Windows. (Well, I guess it's possible that the gs filter
changed assumptions about the dip-switch settings, but that doesn't seem
to fit the randomness.)
> 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.
I'm not using PPD files. I'm using the lpr package and the magicfilter
package (and not using any PPD files with the lpr package).
How can I intercept the bytes that are being sent by lpd
You mean cupsd? Are you trying to run both together?
No and no. I mean lpd from package "lpr". I'm not running them
together:
>> ... I removed CUPS and re-created my previous setup that
>> used lpr and magicfilter for printing.
(I switched back because I thought that would get me back to having
a working printer. Of course, it ended up telling me that the problem
was not in CUPS, and is somewhere else in Sarge (in gs?) or kernel
2.6 (or something else?).)
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 ...
By "device" there I meant the character device /dev/lp0 (as opposed
to the parallel port hardware).
> is gdb (possibly
with ddd or other front end) or a logic analyzer, but these seem like
massive overkill.
Definitely.
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 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?)
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 first shows up in what lpd writes to
/dev/lp0, then lpd is buggy; etc.
How can I check the bytes that are actually being send out from
the kernel to the parallel port (to see [i]f 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?
Which level of "device" do you mean here? (I thought you meant the
hardware, but that can't be swapped out.)
(I meant between the file-system-level device /dev/lp0 and probably
the point in the kernel where it's writing out the sequence of bytes
to the hardware, or possibly at the level of what the hardware
actually got from the kernel.)
I was thinking that if the kernel wasn't handling parallel port
interrupts correctly, it could be dropping bytes or sending
extra bytes.
(Of course, that theory (seemingly) is shot down by the fact that plain
text (seemingly) prints fine.)
Any other ideas?
... 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,
Yes, actually I always have a spare partition and I do have a backup
from right before I upgraded to Sarge.
> you might be able to repeat the upgrade and
isolate the package upgrade which triggered the problem.
I was hoping I wouldn't have to go that far, but I do have the things
required to make it possible...
Thanks.
Daniel
Reply to: