printer problem

[Peter Flynn]

On 25/09/18 19:42, Richard Kimber wrote:
> On Tue, 25 Sep 2018 19:15:24 +0100
> Peter Flynn <peter at silmaril.ie> wrote:
> 
>> Is there anything useful in /var/log/cups/error_log ?
>>
> I have a lot of these:-
> 
> E [25/Sep/2018:17:40:24 +0100] [Client 640] Returning IPP server-error-internal-error for CUPS-Add-Modify-Printer (ipp://localhost/printers/Canon-MX920-series) from localhost
> E [25/Sep/2018:17:40:25 +0100] [CGI] Unable to create PPD file: Printer does not support required IPP attributes or document formats.
> E [25/Sep/2018:17:40:25 +0100] copy_model: empty PPD file

That's the problem. The printer either doesn't support the needed
functionality for a PPD file, OR (as brian said) it's "driverless"
(which is nothing of the sort: the "driver" — actually the Page
Description Language — is just embedded in the printer, not the client).

In theory, with a printer that supports PDF as one of its PDLs, you
should be able to copy the PDF straight to the printer, without using
CUPS at all. In practice, you may need a print monitor/scheduler to
synchronize properly and keep jobs separate IFF you are in a multi-user
environment. The Debian page says:

> Note that we are talking here about sending a job directly to a 
> printer, not to a print queue being advertised by CUPS.

My (very limited) understanding is that CUPS should be able to get
everything it needs to create a PPD file by querying the printer direct.
If it can't (as appears to be the case) then either CUPS is broken and
needs an update, or the printer is not capable of talking to CUPS.

A PPD file is a Postscript Printer Description, which is an ASCII file
(therefore editable) describing to (eg) CUPS exactly what the printer is
capable of (size, speed, resolution, etc). If CUPS can't find one in its
libraries, you have the option of providing one (eg downloaded from
somewhere else). If you don't or can't, and the printer won't tell CUPS
what it can do, you get the result above.

The Debian page on Driverless Printing is a little specious:

> This is not seen as an acceptable situation for mobile clients, 
> which may have limited storage for PPDs and drivers and which may
> lack resources, such as battery power. Neither is it deemed
> particularly realistic for a user to have to set up or reconfigure a
> mobile device for each printer that is encountered. This requires a
> level of expertise and a time and effort commitment that cannot be
> assumed to be possessed.
True for low-power mobile devices, already untrue for most Android
phones, with apps like PrinterShare, which can download and configure
themselves on-the-fly for whatever accessible printer you may be able to
connect to.

We are in a state of transition, like we were with WAP (remember WAP?)
and other historical kludges designed to overcome the limitations of
devices which held true for a few months or maybe a year before
technology took another step forward. In a year or few it'll probably be
irrelevant because mobile devices will just have more speed and space.

All of which probably doesn't solve the problem: you can either ditch
CUPS, which is probably a leap too far right now, or you can find a way
to fudge it with a PPD file that provides the missing information.

///Peter