Re: Apple raster, PWG raster and non-free filters/drivers
On Mon 16 Jan 2017 at 19:09:44 -0200, Till Kamppeter wrote:
> On 01/16/2017 05:17 PM, Brian Potkin wrote:
> >>My question is here whether the Google Cloud Print server polls printer
> >>capability info from the printer or whether it has a database with info
> >>about thousands of printer models? In the latter case we do not have
> >>driverless printing here and a GCP printer has its model capabilities in
> >>Googles database, in addition to understanding one of PWG Raster and PDF.
> >I do not know whether any sort of a database is used, but suspect not.
> > https://developers.google.com/cloud-print/docs/devguide
> >During the registration phase the capabilities are obtained. I can only
> >connect a classic printer and have seen the PPDs of the queues being
> >uploaded (over an XMPP/https connection, I suppose). The downloaded file
> >for a job is a PDF.
> How I understand it now is that a GCP 2.0 printer when registering sends a
> CDD record with its capabilities to the server, so there really seems to be
> no database with printer-model-specific data on the server and so we have
> really driverless printing.
> Your "classic" printer is probably not registering itself, but on your
> computer is a CUPS queue with PPD and driver and the registering process
> (Chrome/Chromium browser) is registering your CUPS queue sending the queue's
> PPD file. It is nor problem to register CUPS queues as they have a PPD and
> they accept jobs in PDF.
I have used cloudprint or google-cloud-print-connector to register the
printers and provide a connector to GCP. (google-cloud-print-connector
is in unstable only. It was removed from testing in the past few days
due to a FTBFS).
GCP will always send a PDF because application/pdf comes before image/pwg
> Now if you want to use a printer whose only driverless mode is GCP 2.0
> directly with your computer, without the internet or Google Cloud Print in
> between, you would need a way to poll the CDD record from the printer (the
> format is documented by Google), but I do not know how to do this, whether
> there is a standard way to do it, or whether it is possible at all. In the
> worst case you will need to make your computer emulating a Google Cloud
> Print server. Google probably provides enough information to do so, but it
> would be a high effort to get this class of printers supported.
cupscloudprint presumably solves the problem of having CUPS access GCP's
printers. It isn't in Debian and the Ubuntu PPA package does not install
> >>So the fact that a printer is a GCP printer only helpos for driverless
> >>printing if Google can actually poll the printer's capabilities from the
> >>printer and if Google publishes the protocol for this kind of poll.
> >The Chromium browser (and Chromebooks, I believe) can do driverless
> >printing through GCP from the point of view of the user.
> This would mean that even for local printing you need to be connected to the
No. Local destinations are still through CUPS (if it is running).
> >The technique
> >does not involves CUPS. I understand the significance of the term
> >"driverless printing" when applied to CUPS+cups-filters+cups-browsed
> >but, at the same time, it is quite a well-used and general term whose
> >implementation depends on the service being used.
> I understand "driverless printing" as, first, not needing any software or
> data which is specific to the printer model on the computer (the "printer
> driver"), in order to use the printer, and second, only data and not code to
> be executed on the computer be polled from the printer in order to use it.
Yes. Note that this also applies with HP's ePrint. So that gives (not
very controllable) driverless printing too.