[Pkg-cups-devel] Bug#533468: Bug might be in SpliX or the printer itself

[Ulrich Eckhardt]

Jeroen, I'm CC'ing you because you are the Debian SpliX maintainer.

I have been looking at the output generated by the filter[1] and at the 
sources of SpliX, which is the one that converts between some rasterized 
format and the one for the printer. The SpliX homepage has a document with 
information about the reverse-engineered protocol where it claims that the 
printer reads a fixed 32-bit value (0x09abcdef) and depending on the byte-
order switches into little endian or big endian mode for the bands, similar to 
a byte-order marker (BOM) under Unicode.

Now, the reason why I don't rule out a printer defect is that it seems that 
the format generated by the driver is correct, according to the spec. However, 
that still doesn't rule out that simply the spec is wrong, after all it's not 
an official document from the printer vendor.

Anyhow, I modified the sources to always create little-endian output and now I 
can at least print. I need to clean up the sources and generate diffs still, 
which won't be before Sunday, but I wanted to give that update here. Maybe 
someone else beats me to it and finds the bug first.

Cheers and good night!

Uli



[1] Copy the following script in /usr/cups/filter/teefilter

#!/bin/bash
cat \
| tee /var/tmp/printjob_$1_in \
| /usr/lib/cups/filter/rastertoqpdl "$1" "$2" "$3" "$4" "$5" $6 \
| tee /var/tmp/printjob_$1_out

and change the line

*cupsFilter: "application/vnd.cups-raster 0 teefilter"

in the copy of the PPD file under /etc/cups/ppd in order to sniff the input 
and output of each printjob.