I’ve been running Manjaro-Xfce, on my HP 64-bit laptop, since September 2019; prior to that, I had been running various versions of LinuxMint-Mate, on Lenovo 32-bit and Acer 64-bit laptops.
The printer in question is a Canon PIXMA MP640, hard wired via cat-5 ethernet cable, to my home wireless network hub. I purchased this printer eleven years ago, and it has served me well ever since, in identically the same configuration, with all three laptops.
Today, LinuxPrinting.org appears to classify the PIXMA MP640 as a “paperweight”. Eleven years ago this was not the case; it was classified as “fully supported”, and my experience shows that it remains so today — the reclassification as “paperweight” is clearly wrong! (However, the GutenPrint drivers do tend to make it behave as a “paperweight” — to attain “fully supported” status, one must use the drivers published by Canon themselves).
I found setting this printer up on Manjaro to be rather tricky. The original Canon drivers are 32-bit, and published only in DEB and RPM formats. There is support in AUR, which failed to build and install, when I first tried it. The problem — which is surely a pacman/pamac bug — arises because the driver is split into two “cnijfilter” packages; one is specific the MP640, while the other is common to several cnijfilter drivers. Pamac correctly identifies that “cnijfilter-mp640” depends on “cnijfilter-common”, but then blithely tries to build and install the former, before the latter, (which isn’t possible, because the dependency is not resolved at cnijfilter-mp640 build time, the build fails, and installation of both is immediately aborted. Only when I realized that I needed to first install cnijfilter-common alone, and then come back later, to install cnijfilter-mp640, was I able to get the printer working; with one (known) exception (specified below), it has worked (mostly) flawlessly, since.
The one exception to flawless operation, of which I am currently aware, is when I attempt to print directly from Scribus; the job is queued, and a few minutes later, the printer status dialogue reports it as “completed”, but no output is actually delivered to the printer, (and the printer’s own control panel shows nothing being received). OTOH, if I export the Scribus document as PDF, then print that from qpdfview, the printer does receive the output, and prints it flawlessly, so I do have a (rather inconvenient) work-around.
FWIW, the behaviour I’m seeing with Scribus was also exhibited by Firefox, following an update in December 2020, but now appears to have been corrected, by a subsequent update. Furthermore, the symptoms observed are reminiscent of the behaviour of the printer, when configured to use the (useless) GutenPrint driver. I have the printer configured to use (the AUR derivative of) Canon’s cnijfilter driver — which does work — but it almost appears as if Scribus is ignoring the system configuration, and trying to use the GutenPrint driver — which does not work — instead.
Any ideas?
