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

[Robert K. <rl...@al...>]

On Mon, 30 Sep 2019 13:07:38 +0200, Till Kamppeter wrote:
> [ 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.

Front ends maybe (just like our GIMP plugin will at best lose a lot of
its raison d'etre), but the backends won't.

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

Right, which is where I've wanted to go all along (I remember some of
those printing summits, back in the day when I actually would travel
on business-ish).

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

I certainly don't want to write a PDF renderer, although maybe poppler
could be used for that purpose (but it has some licensing problems),
but do all applications have a way to generate one of these raster
formats?

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

I don't know the internals of SANE, but I suspect trying to use the
SANE backends without the framework would be a bit like using the
Gutenprint family drivers without such.  Scanning's very different
from printing, and SANE and Gutenprint have no shared development
history so it's pretty unlikely that what we've done and what they
done could be conveniently shoehorned together at a low level.

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

OK.

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

So that means adding a web server...somewhere.

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

I agree with starting there.  But I'd much rather the scanning experts
do the scanning work.  If there has to be a single app for both
printing and scanning, maybe it would make more sense for that to be a
third project (or a joint project between SANE and Gutenprint).  We
can surely kick that particular can down the road for a while, though.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton