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