* [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service @ 2019-11-07 15:34 Till Kamppeter 2019-11-07 16:49 ` Solomon Peachy 0 siblings, 1 reply; 7+ messages in thread From: Till Kamppeter @ 2019-11-07 15:34 UTC (permalink / raw) To: Open Printing Hi, CUPS 2.3.0 came out recently and looking deeper into it, the removal of PPD file support comes closer. If you create a print queue using the lpadmin command, not using "-m everywhere", but any other "-m ..." or "-P ..." argument, causing the queue to get a PPD file in /etc/cups/ppd/, you get the following warning message: lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. With this explicit warning issued by command the removal seems to be close. So we need it to make the next step of development in OpenPrinting to prepare for printer drivers being delivered as Printer Applications. So we need to concentrate on Printer/Scanner Applications and IPP System Service from know on. This is a substantial change in the printing architecture on Posix-style operating systems. Especially we need to create libraries to allow easy creation of Printer/Scanner Applications. They should provide: - Acquisition of a port on localhost (or on all network interfaces for sharing). Managing the port numbers in a useful way. - DNS-SD advertising of the services (printer, scanner, fax, config interfaces, ...) - IPP server: Answering all types of requests and calling functions to do the needed interactions with the printer/scanner and the application- internal printer/scanner capability data. - Processing and filtering the incoming job data: Printer Applications will take PDF and raster formats as input and convert to the printer's native format. Functionality of the filters in cups-filters should be moved into a library, to be available as API functions. - Legacy interface functions: For filters/PPDs and for SANE drivers. - Communication with printers and scanners, functionality of the CUPS backends. - IPP System Service as a server, to allow configuration of the Printer/Scanner Application via an external GUI (IPP System Service client). Then there can even be a Printer Application for a legacy printer which cannot be auto-discovered in the network. The application starts only providing IPP System Service. As soon as the user has entered the printer's IP address via the configuration interface, the application connects to the printer and starts to offer IPP print service. - Perhaps also a web server for legacy clients. Then commodity functions of the library for building up a configuration interface should add each interface element to both the IPP System Service server and the web server. - IPP System Service as a client, for GUI (and also CLI) apps to configure IPP printers and also Printer/Scanner Applications. This will be a central part of printer setup tools in the future. For testing this we should create a native Printer Application from Gutenprint for example, or one for PostScript printers for which we have PPD files. We also should create a native Scanner Application wrapping SANE with its current driver collection. Additional things to do: - Turn cups-browsed into a Printer Application: Instead of creating a local CUPS queue for a printer cluster emulate an IPP printer which prints to the cluster (and local CUPS picks it up automatically, but how to prevent local CUPS from seeing the member printers directly?). We can also pick up legacy CUPS broadcasts (or BrowsePoll from legacy servers) and provide these printers as IPP printers. Configuration of cups-browsed then also via IPP System Service. - Overtake PPD support API functions and pstops filter as soon as they get dropped from CUPS, for legacy support in Printer Aplications and cups-browsed. - SANE driver for IPP scanners, so that applications accessing scanners via SANE can also access IPP scanners and Scanner Applications. Documentation/Community reach-out: - Design guidelines for printer and scanner drivers as Printer/Scanner Applications, instructions to do this with our new libraries. - As soon as SANE is wrapped into Scanner Applications, move GUI developers to base their scan frontends on IPP scanning and not SANE any more. The code should get preferably hosted at OpenPrinting as part of cups-filters or in separate projects/repositories. Probably we need to overtake some parts of the ippsamples code. Or should the lib then better be at the PWG as part ippsamples? Till ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service 2019-11-07 15:34 [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service Till Kamppeter @ 2019-11-07 16:49 ` Solomon Peachy 2019-11-07 19:14 ` Till Kamppeter 0 siblings, 1 reply; 7+ messages in thread From: Solomon Peachy @ 2019-11-07 16:49 UTC (permalink / raw) To: Open Printing [-- Attachment #1: Type: text/plain, Size: 3426 bytes --] On Thu, Nov 07, 2019 at 04:34:32PM +0100, Till Kamppeter wrote: > - Legacy interface functions: For filters/PPDs and > for SANE drivers. (all of my comments are limited to printing, not SANE) I'm not sure what form this can meaningfully take, other than effectively being "Legacy CUPS in a container" In my view there are really two parallel thrusts; Wrapping existing legacy CUPS drivers, and the brave new world of native-IPP solutions. Where they are similar is in their interfacing to the outside system (OS integration, port selection, dns-sd, and so forth but once you step past that, they diverge rapidly. For example, CUPS filter wrapping is necessarily PPD-centric, but that's a lot of baggage (and complexity) that is presumably unnecessary for native, directly-integrated stuff. > - Communication with printers and scanners, > functionality of the CUPS backends. Most printers can get away with the standard legacy CUPS backends, but there are custom backends to contend with (often proprietary), and a lot of quirks just to keep life interesting. > For testing this we should create a native Printer Application from > Gutenprint for example, or one for PostScript printers for which we have PPD > files. We also should create a native Scanner Application wrapping SANE with > its current driver collection. Gutenprint is a good canidate for this as, at its core, it is a library that provides a rich API for printer description, configuration, and rasterization. Its existing CUPS driver and GIMP plugin are effectively stand-alone applications that rely on that library, and would presumably be a decent example of how one would need to integrate third party code into any printer application framework. Gutenprint's CUPS backends are sort of bolted onto the side, and typically support extensive printer configuration/status reporting and issuing OOB commands, areas where the IPP model offers substantial benefits over the (significant) inadequacies of the legacy CUPS model. ...suffice it to say I'm really looking forward to a native IPP wrapper around Gutenprint, and will help any way I can. > The code should get preferably hosted at OpenPrinting as part of > cups-filters or in separate projects/repositories. Probably we need to > overtake some parts of the ippsamples code. Or should the lib then better be > at the PWG as part ippsamples? I agree that this effort will require subsuming substantial chunks of the ippsample code, if only because of tight integration requirements that probably don't align well with ippsample's existing codebase. But IMO a development goal here would be to try to keep the IPP stuff self-contained, and if restructuring is necessary, try to convinve upstream ippsample to accept those changes as to minimize everyone's maintenance burdens. Oh, one are of concern here is licensing; As well as chosing a license for the (substantial) new code that needs writing, of the code we'd presumably want to re-use or otherwise integrate, there's quite an assortment. For example, ippsample is ASL2, gutenprint is GPL2+, and cups-filters is a mismash of GPL2, GPL2+, GPL3, GPL3+, and MIT. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service 2019-11-07 16:49 ` Solomon Peachy @ 2019-11-07 19:14 ` Till Kamppeter 2019-11-08 2:06 ` Solomon Peachy 0 siblings, 1 reply; 7+ messages in thread From: Till Kamppeter @ 2019-11-07 19:14 UTC (permalink / raw) To: Solomon Peachy, Open Printing On 07/11/2019 17:49, Solomon Peachy wrote: > On Thu, Nov 07, 2019 at 04:34:32PM +0100, Till Kamppeter wrote: >> - Legacy interface functions: For filters/PPDs and >> for SANE drivers. > > (all of my comments are limited to printing, not SANE) > > I'm not sure what form this can meaningfully take, other than > effectively being "Legacy CUPS in a container" > > In my view there are really two parallel thrusts; Wrapping existing > legacy CUPS drivers, and the brave new world of native-IPP solutions. > The wrapping of existing legacy CUPS drivers method is only for the case that such drivers exist and it is not worthwhile or possible to rewrite the drivers to get native IPP applications. This is for example the case with - Proprietary drivers from which we do not have the source code - Drivers for old printers which are not maintained any more and no one wants to dive into the driver's internals - Quick solution to not loose functionality/hardware support in a Linux distribution when the first CUPS without PPD support appears and some drivers are not yet converted. The preferable way are native IPP applications. Whenever possible, especially for new drivers or for drivers which are actively maintained, like Gutenprint or HPLIP this is the way to go. > Where they are similar is in their interfacing to the outside system > (OS integration, port selection, dns-sd, and so forth but once you > step past that, they diverge rapidly. For example, CUPS > filter wrapping is necessarily PPD-centric, but that's a lot of > baggage (and complexity) that is presumably unnecessary for native, > directly-integrated stuff. > See above. >> - Communication with printers and scanners, >> functionality of the CUPS backends. > > Most printers can get away with the standard legacy CUPS backends, but > there are custom backends to contend with (often proprietary), and a lot > of quirks just to keep life interesting. > Any custom backend code can go into the Printer Application, either as existing CUPS backends or in the code of a native IPP application. >> For testing this we should create a native Printer Application from >> Gutenprint for example, or one for PostScript printers for which we have PPD >> files. We also should create a native Scanner Application wrapping SANE with >> its current driver collection. > > Gutenprint is a good canidate for this as, at its core, it is a library > that provides a rich API for printer description, configuration, and > rasterization. Its existing CUPS driver and GIMP plugin are > effectively stand-alone applications that rely on that library, and > would presumably be a decent example of how one would need to integrate > third party code into any printer application framework. > Therefore I also first thought about Gutenprint to get the first native Printer Application. > Gutenprint's CUPS backends are sort of bolted onto the side, and > typically support extensive printer configuration/status reporting and > issuing OOB commands, areas where the IPP model offers substantial > benefits over the (significant) inadequacies of the legacy CUPS model. > Is it not the case that the only backend coming with Gutenprint currently is the USB backend for the dye sublimation printers with proprietary USB protocol? > ...suffice it to say I'm really looking forward to a native IPP wrapper > around Gutenprint, and will help any way I can. > >> The code should get preferably hosted at OpenPrinting as part of >> cups-filters or in separate projects/repositories. Probably we need to >> overtake some parts of the ippsamples code. Or should the lib then better be >> at the PWG as part ippsamples? > > I agree that this effort will require subsuming substantial chunks of > the ippsample code, if only because of tight integration requirements > that probably don't align well with ippsample's existing codebase. > > But IMO a development goal here would be to try to keep the IPP stuff > self-contained, and if restructuring is necessary, try to convinve > upstream ippsample to accept those changes as to minimize everyone's > maintenance burdens. > With restructuring you mean here to spin out the functional code of the ippsample utilities into a library and provide an API? > Oh, one are of concern here is licensing; As well as chosing a license > for the (substantial) new code that needs writing, of the code we'd > presumably want to re-use or otherwise integrate, there's quite an > assortment. For example, ippsample is ASL2, gutenprint is GPL2+, and > cups-filters is a mismash of GPL2, GPL2+, GPL3, GPL3+, and MIT. Most GPLish of cups-filters is inherited from CUPS, so we can probably turn it into ASL2. Till ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service 2019-11-07 19:14 ` Till Kamppeter @ 2019-11-08 2:06 ` Solomon Peachy 2019-11-08 10:57 ` Andreas Radke 0 siblings, 1 reply; 7+ messages in thread From: Solomon Peachy @ 2019-11-08 2:06 UTC (permalink / raw) To: Open Printing [-- Attachment #1: Type: text/plain, Size: 1371 bytes --] On Thu, Nov 07, 2019 at 08:14:59PM +0100, Till Kamppeter wrote: > - Quick solution to not loose functionality/hardware support in a Linux > distribution when the first CUPS without PPD support appears and some > drivers are not yet converted. I think this should be the primary beneficiary. I'm personally not going to lose any sleep over already-abandoned proprietary drivers that were never really supported to begin with. :) > The preferable way are native IPP applications. Whenever possible, > especially for new drivers or for drivers which are actively maintained, > like Gutenprint or HPLIP this is the way to go. Absolutely. > Is it not the case that the only backend coming with Gutenprint currently is > the USB backend for the dye sublimation printers with proprietary USB > protocol? Correct, althrough there are also some utilites for administrative actions on some inkjet families (alignment, cleaning, etc). > With restructuring you mean here to spin out the functional code of the > ippsample utilities into a library and provide an API? Yes, ideally with the cooperation of the ippsample authors. IMO it would be a win-win for everyone. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service 2019-11-08 2:06 ` Solomon Peachy @ 2019-11-08 10:57 ` Andreas Radke 2019-11-08 13:33 ` Solomon Peachy 0 siblings, 1 reply; 7+ messages in thread From: Andreas Radke @ 2019-11-08 10:57 UTC (permalink / raw) To: printing-architecture [-- Attachment #1: Type: text/plain, Size: 1289 bytes --] Am Thu, 7 Nov 2019 21:06:31 -0500 schrieb Solomon Peachy <pizza@shaftnet.org>: > On Thu, Nov 07, 2019 at 08:14:59PM +0100, Till Kamppeter wrote: > > - Quick solution to not loose functionality/hardware support in a > > Linux distribution when the first CUPS without PPD support appears > > and some drivers are not yet converted. > > I think this should be the primary beneficiary. I'm personally not > going to lose any sleep over already-abandoned proprietary drivers > that were never really supported to begin with. :) If some big player wants to keep PPD driver support alive they should keep maintaining a cups 2.3.x fork until the last non-IPP driven device is dead. > > The preferable way are native IPP applications. Whenever possible, > > especially for new drivers or for drivers which are actively > > maintained, like Gutenprint or HPLIP this is the way to go. > > Absolutely. > IPP without any backward compatibility should be the preferred way to go. When cups 2.4.x will be out I will probably disable any ppd driven driver support in Arch. Just to stop people using closed source driver and to push open standards. Anything else will probably go into our community maintained unsupported AUR repositories. -Andy Arch Linux [-- Attachment #2: Digitale Signatur von OpenPGP --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service 2019-11-08 10:57 ` Andreas Radke @ 2019-11-08 13:33 ` Solomon Peachy 2019-11-08 17:15 ` Michael Sweet 0 siblings, 1 reply; 7+ messages in thread From: Solomon Peachy @ 2019-11-08 13:33 UTC (permalink / raw) To: Andreas Radke; +Cc: printing-architecture [-- Attachment #1: Type: text/plain, Size: 962 bytes --] On Fri, Nov 08, 2019 at 11:57:51AM +0100, Andreas Radke wrote: > When cups 2.4.x will be out I will probably disable any ppd driven > driver support in Arch. Just to stop people using closed source driver > and to push open standards. Anything else will probably go into our > community maintained unsupported AUR repositories. It's not proprietary drivers I'm concerned about -- There's a _huge_ install base of SMB-exported or native networked PCL/PS+PPD printers, and MajorDistros(tm) can't get away with just dropping legacy CUPS before there is a JustWorking(tm) alternative folks' existing printers. The goal ahead is good, and very much achievable, but as Till's original email laid out, it's a pretty long road and we're not exactly drowning in manpower... - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service 2019-11-08 13:33 ` Solomon Peachy @ 2019-11-08 17:15 ` Michael Sweet 0 siblings, 0 replies; 7+ messages in thread From: Michael Sweet @ 2019-11-08 17:15 UTC (permalink / raw) To: Solomon Peachy; +Cc: printing-architecture Solomon, > On Nov 8, 2019, at 8:33 AM, Solomon Peachy <pizza@shaftnet.org> wrote: > > On Fri, Nov 08, 2019 at 11:57:51AM +0100, Andreas Radke wrote: >> When cups 2.4.x will be out I will probably disable any ppd driven >> driver support in Arch. Just to stop people using closed source driver >> and to push open standards. Anything else will probably go into our >> community maintained unsupported AUR repositories. > > It's not proprietary drivers I'm concerned about -- There's a _huge_ > install base of SMB-exported or native networked PCL/PS+PPD printers, > and MajorDistros(tm) can't get away with just dropping legacy CUPS > before there is a JustWorking(tm) alternative folks' existing printers. Even at Apple, we are quite aware that some of our customers depend on SMB printing. Our focus is on enterprise-class printers (so PostScript and PCL) which can largely be supported using "generic" drivers already, which means something like ippeveprinter (running as the logged-in user, which has the side benefit of cleaning up Kerberos support) to act as the software that talks to the SMB server. _________________________________________________________ Michael Sweet, Senior Printing System Engineer ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-11-08 17:15 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-07 15:34 [Printing-architecture] Upcoming work for OpenPrinting: Printer (Scanner) Applications and IPP System Service Till Kamppeter 2019-11-07 16:49 ` Solomon Peachy 2019-11-07 19:14 ` Till Kamppeter 2019-11-08 2:06 ` Solomon Peachy 2019-11-08 10:57 ` Andreas Radke 2019-11-08 13:33 ` Solomon Peachy 2019-11-08 17:15 ` Michael Sweet
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.