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

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

On 01/10/2019 04:55, Robert Krawitz wrote:
>> 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.
> 

I mean that within the Printer Application the SANE frontend/backend 
interface is not necessarily needed. One could make the application 
directly talk to the scanner.

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

A PDF renderer is not needed at all by the Printer Application. There 
are driverless IPP printers around which do not understand PDF, they 
only accept one or more of the raster formats Apple Raster, PWG Raster, 
and/or PCLm.So you let your Printer Application emulate such a 
raster-only printer. Then you only need to convert the incoming raster 
data to the raster format of the actual printer using libgutenprint. No 
PDF interpreter and no fonts needed.

On a desktop system with your Printer Application running CUPS would 
pick up your emulated PPD printer, create a temporary queue and run a 
filter chain to turn the application's PDF output into one of the raster 
formats which the Printer Application needs.

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

Then probably it is perhaps the easiest approach to add a SANE fromtemd 
to the Printer Application and include the appropriate SANE backends 
which support Gutenprint-driven MF devices to the package.

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

I think joint Gutenprint/SANE project would be the best here.

In the end you emulate an IPP multi-function device which does both 
printing and scanning.

    Till