Bug#931560: closed by Brian Potkin (Re: Bug#931560: cups-backend-bjnp: refuses to print with "out of paper" error)

2019-08-16 Thread Leonardo Brondani Schenkel
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 

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.

Bug#931560: cups-backend-bjnp: refuses to print with "out of paper" error

2019-08-14 Thread Louis Lagendijk
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:

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 


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

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

Bug#931560: cups-backend-bjnp: refuses to print with "out of paper" error

2019-07-07 Thread Leonardo Brondani Schenkel
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: 000.010 cups-bjnp: argv[0] = 

   DEBUG: 000.010 cups-bjnp: argv[1] = 6
   DEBUG: 000.010 cups-bjnp: argv[2] = root
   DEBUG: 000.010 cups-bjnp: argv[3] = Test Page
   DEBUG: 000.010 cups-bjnp: argv[4] = 1
   DEBUG: 000.010 cups-bjnp: argv[5] = 
job-originating-host-name=localhost date-time-at-creation= 
date-time-at-processing= time-at-creation=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 = 
series;CLS:PRINTER;DES:Canon MG6100 

   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: 








   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)

Bug#931560: cups-backend-bjnp: refuses to print with "out of paper" error

2019-07-07 Thread Leonardo Brondani Schenkel
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)
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