[Gimp-print-devel] Printer Applications - The new architecture for Gutenprint

[Till K. <til...@gm...>]

[ Changed subject to not have something that important hiden under
   Samsung 1630 ]

On 28/09/2019 20:35, Robert Krawitz wrote:
>> Yes, that is the way to go, also for non-Mac-OS-X systems we want to get rid of the 1980's hack. Therefore we are already working on this at OpenPrinting. Printer Applications (this is how these local IPP servers are called) will not only be able to replace classic printer drivers but also SANE scanner drivers (there is also an IPP driverless scanning standard) and even configuring the Printer Application and the Printer and also maintaining/cleaning/firmware-updating the printer (for all this there is IPP System Service). So a Printer Application can support a multi-function device with all its bells and whistles.
> 
> Perhaps there needs to be a separate project that builds a Printer
> Application for both Gutenprint and SANE.  The two projects have both
> developed for many years with no commonality at all between
> architecture, much less code base, but both projects export a common
> API (at least for basic operations, in our case -- we don't have a
> common API for e. g. status readback and maintenance operations).
> 
> Till, are you in touch with the SANE people at all?
> 

SANE is not really needed here, as we do not want to do a 
wrapper/converter Printer Application as it was created in this year's 
Google Summer of Code but a native one. As PPDs get eliminated, SANE 
will also get eliminated.

The application will run an IPP server, like the "ippserver" in

https://github.com/istopwg/ippsample

The server should especially do the following actions:


1. Inform client about the printer's capabilities on request 
(get-printer-attributes). The information comes from the libgutenprint 
library.

2. Print: The conversion of incoming data (PWG/CUPS/Apple Raster) into 
the printer's native code is also done with libgutenprint. 
PDF/PostScript rendering and fonts are not needed at all (by letting the 
IPP server REQUIRE only the three raster formats and not accept PDF as 
input).

3. For scanning devices are probably only supported if they are 
supported by a SANE driver. This code could be used also in our Printer 
Application, preferably even without the SANE interface. The code at 
least lells us the communication protocol for scanning on Epson (Canon) 
scanners. In a first approach one could work as a SANE client here and 
use the SANE drivers but ideally, one should extend libgutenprint for 
listing scan capabilities and also providing the scanner driver.

4. IPP System Service: This is the IPP standard to provide 
configuration/maintenance/cleaning/firmware update interface in an 
OS-independent way. escputil should go in here for example.

5. Web interface: As there are no GUI frontends for using the IPP System 
Service yet, it is useful to also provide the 
configuration/maintenance/cleaning options in a web interface.


My recommendation is to do the Printer Application for Gutenprint as a 
part of the Gutenprint project, even if we connect to scanner drivers 
with SANE in the beginning, as most of the driver part comes from 
Gutenprint and scanning should be sooner or later move over from SANE to 
Gutenprint.

Also not all of these components need to be done at once. Most important 
is the printing support (part 1 and 2). The other components can be 
added later.

    Till