Re: Gutenprint Printer Application (Native)

On 23/09/2021 03:45, Robert Krawitz wrote:
> 
> Aye, there's the bottom line.  If PAPPL restrictions don't allow us to properly meet the needs of
> our user base, then that's just not an option for us.  I desperately want to get away from PPD
> files; I've never cared for them and I've been ranting off and on about the subject for 20 years
> now.  But replacing them with something that's actually a lot less capable is a non-starter.  We'd
> be better off basing it on libgutenprintui2 and properly CUPS-enabling that.
> 

The only restriction which is in the way for us seems to be the number 
of vendor-specific options. I have simply raised it in the source code 
of the PAPPL in my Printer Application Snap and now one has access to 
all options (see my other mail on this list). My Gutenprint Printer 
Application is ready for testing in the Snap Store.

Internally, it uses PPD files, as it is a CUPS-driver-retro-fit type of 
Printer Application, but in the user experience with it, the PPD files 
are completely invisible. So it is some working model to try out how a 
Gutenprint Printer Application based on PAPPL which gives access to all 
the options looks like. It also does the mapping from standard IPP 
attributes to appropriate PPD option settings, allowing both 
sophisticated all-bells-and-whistles printing and printing from 
restricted clients which only use standard IPP attributes and symmetric 
resolutions.

A native Gutenprint Printer Application would have the same 
functionality but without the restriction to what PPDs can represent you 
have much more liberty how to present the options in the web interface.

Please test my Gutenprint Printer Application with different printer 
models and report issues and feature requests, and also post pull 
requests on

https://github.com/OpenPrinting/gutenprint-printer-app/

    Till