|
From: Till K. <til...@gm...> - 2021-09-23 15:57:14
|
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 |