hello,
Upstream developer/maintainer here.
Leonardo informed me of this bug, so I investigated the issue. It is
indeed related to the ink level implementation, but I do NOT regard
this as a bug.

Based on the logfile provided:

>From the report in ReadData it has:
CTK:M,IO,/,PBK,IO,/,GY,IO,/,BK,SET,/,C,IO,/,Y,LOW

So:
M: Magenta IO (ink out)
PBK: photo black: IO (ink out)
BK: normal black SET (ok)
C: Cyan: IO (ink out)
Y: Yellow: LOW (low but can still print)

any IO (ink out) value indeed stops the printing. Now I understood that
some(?) printers may continue to print under Windows as long as black
(I assume BK or was it PBK) does not run out, but see below.

When you check the actual levels 

CIR:M=000,PBK=000,GY=000,BK=100,C=000,Y=010;

you will see that most cartridges were empty (M, PBK, C were at 0, only
Y had some ink left. BK was 100% (values are in %), so continuing to
print might be dangerous for the print head UNLESS the printer or the
printer driver knows that it should not use the nozzles for those
colors. You will still get a bad quality printout, probably B/W only if
the printer can handle this on its own, without endangering the print
head.

The windows driver apparently has a way to notify the user and ask for
confirmation. It will quite likely avoid emitting any color info in the
printout, hence there is no danger to the print head.

This avoiding color is something we cannot do within CUPS, as the
backend receives an already rendered image. So I think that solving
this is not desirable (it would be only a one line change, but I am
really reluctant to change it as printing colors when the cartridge may
damage the printhead).

Your bug report caused me to find one real bug though, whereby CUPS
reports an out of paper instead of an out of ink. This will be solved
in the 2.0.3 version, due out later this week

Reply via email to