printer problem

[Brian]

On Tue 25 Sep 2018 at 22:05:27 +0100, Peter Flynn wrote:

> 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).

That's the whole point. "driverless" refers to what the client has to
do; it shouldn't have to care about which vendor-specific file to send,
which it does have to do with legacy printing. The PDL accepted by the
printer should be vendor-neutral. All the client has to do is generate
a suitable file for printing.

Contrast this with the legacy situation. A Brother printer wants one
type of file. A canon printer yet another type. An HP printer a third
type. Then, each printer within these three types requires a different
capability file (a PPD).

Gets complicated, eh? I'd take driverless any time of the day. Generate
Apple Raster for all AirPrint-capable printers. That's it. It doesn't
matter which printer I've purchased or am using - CUPS + cups-filters
prints to them all without my having to do any setup.

> 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:

PDF is fine as a PDL. Substitute "PDF" for "Apple Raster" in what is
above. Note that PDF direct printers are less common at the lower end
of the market than AirPrint printers.

> > 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.

Correct - when the system is set up to print driverlessly. It can be
done by cups-browsed too. IPP has to be supported by the printer.

> 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.

The OP isn't taking advantage of the driverless possibilities of his
printing system or printer. Your point is moot.
 
> 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.

Low-power is of not of consequence for the principles of driverless
printing. It is a practical feature of some battery powered devices
when CPU cycles, etc are used to process a job.

Incidentally the paragraph you quote from the wiki should be read in
conjunction with its preceding paragraph for context.

> 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.

A laptop is a mobile device. The same principles of driverless printing
apply here as well.

> 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.

Ditch CUPS for what?

-- 
Brian.