Bug#931560: closed by Brian Potkin (Re: Bug#931560: cups-backend-bjnp: refuses to print with "out of paper" error)
Although I completely understand Louis' reasoning that still leaves recent bjnp-cups unusable for people like me. I would like to give a bit more background about my use case and suggest a couple of alternative solutions. My use case: This specific printer, MG-6150, wastes ink like crazy due to "cleaning up" every time is powered up and after a number of pages being printed (I wish I knew that before buying it). I bought it to print my own pictures once in a while, but most of the time I use it as a "normal" printer to print documents, receipts, etc. Because the printer wastes color ink even when printing B (which should only use the BK ink) due to the frequent cleaning, I have resigned myself to print my color pictures in batches up to the point where the color ink is almost gone, and then just continue to use it as B printer using only the BK ink -- until I have a number of pictures I would like to print again, and then I refill all color inks and print all those pictures. So what I have done is to configure two printers in CUPS, one for "normal" printing which is set to B, normal paper and low resolution, etc. There is another "photo" printer which is set to color, photo paper, etc. Recent versions of bjnp-cups break this use case, since they refuse to print if any ink cartridge is empty, even if only the BK cartridge would be used (this use case works with the Windows driver). Now, as I said, I totally understand why you don't want to have a default which could potentially fry users' print heads if they're not careful. So I have two suggestions: 1. Allow printing if the output is B and there is BK ink. I don't know enough about CUPS internals to know if this sort of metadata is available to the backend at printing time. This would be ideal since that would work out of the box and it would be safe. 2. Otherwise, have a backend setting configurable via URL query parameter in which you tell the backend to skip the ink checks. Ideally there could be one parameter for skipping just the color inks and one for all inks. Power users like me can opt in to this behaviour, and assume full responsibility for any damage they might cause to their printers due to misuse (that won't be any worse than the situation on versions < 2.0). This won't affect anybody, unless they read the docs and understand how to enable this (and the risks). I urge you to consider one of the suggestions above. I believe that this bug should not really be closed because bjnp-cups >= 2.0 breaks the use case of using the printer as B printer, which works with the official Canon drivers and used to work with bjnp-cups < 2.0. Please let me know if I can be of any help.
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
I'm including the bjnp_log of test page that fails to print, with cups-backend-bjnp=2.0.1-1. The same messages repeat every 30s (automatic retries). I have redacted host names and IP addresses. WARNING: 000.010 BJNP logging to /var/log/cups/bjnp_log, debug level = DEBUG DEBUG: 000.010 cups-bjnp: argv = bjnp://redacted:8611/?debuglevel=DEBUG DEBUG: 000.010 cups-bjnp: argv = 6 DEBUG: 000.010 cups-bjnp: argv = root DEBUG: 000.010 cups-bjnp: argv = Test Page DEBUG: 000.010 cups-bjnp: argv = 1 DEBUG: 000.010 cups-bjnp: argv = job-uuid=urn:uuid:1506ebb4-b195-364c-4ec8-871420d2e58f job-originating-host-name=localhost date-time-at-creation= date-time-at-processing= time-at-creation=1562518460 time-at-processing=1562518460 DEBUG: 000.012 Connecting to 10.xx.xx.xx port 8611 (IPv4) DEBUG: 000.012 Sending UDP command to 10.xx.xx.xx port 8611(IPv4) DEBUG: 000.132 Sending UDP command to 10.xx.xx.xx port 8611(IPv4) INFO: 000.134 Identity = MFG:Canon;CMD:BJL,BJRaster3,BSCCe,NCCe,IVEC,IVECPLI;SOJ:TXT01,BJNP2,BJNPe;MDL:MG6100 series;CLS:PRINTER;DES:Canon MG6100 series;VER:1.040;STA:19;FSI:03;HRI:5;MSI:DAT,E5,HFSF;PDR:4;PSE:ACAM61205; DEBUG: 000.134 Printer model = Canon MG6100 series DEBUG: 000.134 Sending UDP command to 10.xx.xx.xx port 8611(IPv4) INFO: 000.137 Printer status: http://www.canon.com/ns/cmd/2008/07/common/; xmlns:cijn="http://www.canon.com/ns/wdp/2008/01/print/;> GetStatusResponse OK idle MarkerSupplyAttention BSCCe BST:04;PID:00,00,00;CHD:CL;LVR:GAL,AT;MID:141D20;CTK:M,IO,/,PBK,IO,/,GY,IO,/,BK,SET,/,C,IO,/,Y,LOW;CIR:M=000,PBK=000,GY=000,BK=100,C=000,Y=010;DJS:NO;DBS:NO;DWS:1500,1570;DOC:4,00,NO;DSC:NO;FSI:03;HRI:5;PRC:2,0;MSI:DAT,E5,HFSF;PDR:4;HRC:NO;TCA:M,AC,/,PBK,AC,/,GY,AC,/,BK,AC,/,C,AC,/,Y,AC; 288 DEBUG: 000.137 Read printer status: 4, Printing = 0, Busy = 0, Error = 0 DEBUG: 000.137 Sending UDP command to 10.xx.xx.xx port 8611(IPv4)
Package: cups-backend-bjnp Version: 2.0.1-1 Severity: important Tags: upstream Dear Maintainer, Printer: Canon PIXMA MG6150 Backend: bjnp Upgraded to Debian buster, cups now refuses to print with error "Network host '...' is out of paper, will retry in 30 seconds..." Tried restarting the printer, restarting cups, manually removing 'Reason' lines from /etc/cups/printers.conf (while cups is off), nothing solved the issue. I took a look at upstream changelog and noticed this for 2.0: > Ink level reporting is added as well as improved error handling. I suspected that there could be a regression, so I downgraded the package (and only this package) to the version in stretch (1.2-2) and the problem went away instantly. I didn't even need to restart cups: the new bjnp backend started printing in the next automatic retry. Tried upgrading again and problem returned; downgraded and problem disappeared. Note that I have a few ink cartdriges that are nearly running out, but not low enough that the printer refuses to print. It could be possible that the new ink level reporting code is misinterpreting this condition as an "out of paper" condition. Unfortunately I don't have new cartdriges at hand to test this hypothesis. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.0.15-1-pve (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups-backend-bjnp depends on: ii libc6 2.28-10 ii libcups2 2.2.10-6 Versions of packages cups-backend-bjnp recommends: ii printer-driver-gutenprint 5.3.1-7 cups-backend-bjnp suggests no packages. -- no debconf information