* [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems @ 2020-07-28 22:33 Till Kamppeter 2020-07-29 5:24 ` Zdenek Dohnal ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Till Kamppeter @ 2020-07-28 22:33 UTC (permalink / raw) To: Marek Kasik Cc: Aveek Basu, Open Printing, Rithvik Patibandla, Rithvik Patibandla Marek, I want to make you aware of the state of the GTK print dialog and problems which are occuring with it in modern printing environments. Most (probably all) of these can be solved by adding CPDB (Common Print Dialog Backends) support to the dialog as then the control on how the dialog communicates with printing systems is moved from GTK to OpenPrinting. We at OpenPrinting can quickly react to changes and implement everything needed in the appropriate CPDB backend. Unfortunately Tanmay Anand refuses to answer to any of our requests to return to working on this subject. I do not know how well you worked together with him, how much code and which quality of code he contributed, whether he actualy understood all the mechanisms, ... Could you tell about your relationship with him in this subject? Is there any worthwhile outcome which could be the base for someone else to continue and complete the work? Are there any plans to add CPDB support independent of Tanmay? Problems are the following: 1. If there is an IPP printer available CUPS would create a temporary queue as soon as you try to print on such a printer. See the output of lpstat -l -e for such queues. On my machine I get till@till-x1yoga:~/Downloads$ lpstat -l -e HP_OfficeJet_Pro_8730_08C229_ network none ipps://HP%20OfficeJet%20Pro%208730%20%5B08C229%5D._ipps._tcp.local/ HP_OfficeJet_Pro_8730_08C229_USB_ network none ipp://HP%20OfficeJet%20Pro%208730%20%5B08C229%5D%20(USB)._ipp._tcp.local/ Label_Printer network none ipps://Label%20Printer._ipps._tcp.local/ Office_Printer network none ipps://Office%20Printer._ipps._tcp.local/ snap-ps permanent ipp://localhost/printers/snap-ps ipp://HP%20OfficeJet%20Pro%208730%20%5B08C229%5D._ipp._tcp.local/ snap_ps_till_x1yoga network none ipps://snap-ps%20%40%20till-x1yoga._ipps._tcp.local/cups till@till-x1yoga:~/Downloads$ The ones with "permanent" a standard CUPS queues which the print dialog happily lists. The one with "network" CUPS would only create on-demand. These are not listed by the print dialog and should be listed. Michael Sweet has made a new (already years ago) CUPS API for that, using the cupsEnumDests() functions. 2. The GTK print dialog seems to list IPP printers diectly from DNS-SD, these even show if no CUPS daemon at all is running on the system, suggesting that the dialog prints spooler-less to these printers, and as many of these do not spool by themselves one can expect the application to hang (if the GTK dialog has no mini spooler built in). Queue names seem to be constructed from the DNS-SD service name. 3. I have tried to print on such independent-of-CUPS IPP printers and ran into two problems: a. One printer comes from the sample Printer Application from the PAPPL project. It does not accept PDF input, only Raster formats. The dialog seems to happily send PDF jobs to this printer (which get aborted by the Printer Application). So before listing arbitrary DNS-SD-reported IPP printers, the TXT record of the printer needs to get checked and whether in its "pdls" entry PDF (or the job's format) is listed. Only then the printer can be listed. b. I have a physical IPP network printer which does driverless IPP printing. It advertises itself by DNS-SD (and so the dialog always lists it, also without CUPS running), understands PDF, and you get all needed properties of the printer if you send a get-printer- attributes IPP request to it. This allows me driverless printing with CUPS. The GTK dialog seems to be sending something else than a get-printer-attributes IPP request to the printer, as when I select the printer in the dialog, the dialog never completes getting the printer's properties. The "Print" stays permanently grayed and the status stays permanently on "Getting Printer Information". GTK dialog backends on the system are the following: ill@till-x1yoga:~/Downloads$ ls /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/ libprintbackend-cloudprint.so libprintbackend-file.so libprintbackend-test.so libprintbackend-cups.so libprintbackend-lpr.so till@till-x1yoga:~/Downloads$ dpkg -S /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/* libgtk-3-0:amd64: /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-cloudprint.so libgtk-3-0:amd64: /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so libgtk-3-0:amd64: /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-file.so libgtk-3-0:amd64: /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-lpr.so libgtk-3-0:amd64: /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-test.so till@till-x1yoga:~/Downloads$ Everything coming from my Ubuntu 20.04, no experiments performed, no student's code tried out here. I assume that all these problems originate in the libprintbackend-cups.so module. So my suggestion is to get CPDB support into the GTK dialog. How should we proceed here? Rithvik, would you perhaps volunteer or at least in some form help? Till ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems 2020-07-28 22:33 [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems Till Kamppeter @ 2020-07-29 5:24 ` Zdenek Dohnal 2020-07-29 12:07 ` Till Kamppeter [not found] ` <e3c06595-f150-02e6-5d44-f7565a620b3c@redhat.com> [not found] ` <CA+tVraiqkkoKRaO8Pe8HOzJpi4FD=PC1-wCHacQ6L-Tht934Lg@mail.gmail.com> 2 siblings, 1 reply; 8+ messages in thread From: Zdenek Dohnal @ 2020-07-29 5:24 UTC (permalink / raw) To: Till Kamppeter, Marek Kasik Cc: Aveek Basu, Open Printing, Rithvik Patibandla, Rithvik Patibandla [-- Attachment #1.1: Type: text/plain, Size: 8073 bytes --] Hi Till, I and Marek are working on the most of issues you mentioned here https://bugzilla.redhat.com/show_bug.cgi?id=1784449 , but I didn't propose cpdb support for it, because I wasn't sure of readiness of the project after GSoC. IIRC Ubuntu doesn't ship cpdb either and you mention the person who should oversee the project is unresponsive, so it would need time to learn about the project and probably make some changes to get it into GTK - I'm not sure whether implementing the current CUPS API wouldn't be faster. On 7/29/20 12:33 AM, Till Kamppeter wrote: > Marek, > > I want to make you aware of the state of the GTK print dialog and > problems which are occuring with it in modern printing environments. > > Most (probably all) of these can be solved by adding CPDB (Common > Print Dialog Backends) support to the dialog as then the control on > how the dialog communicates with printing systems is moved from GTK to > OpenPrinting. We at OpenPrinting can quickly react to changes and > implement everything needed in the appropriate CPDB backend. > > Unfortunately Tanmay Anand refuses to answer to any of our requests to > return to working on this subject. I do not know how well you worked > together with him, how much code and which quality of code he > contributed, whether he actualy understood all the mechanisms, ... > Could you tell about your relationship with him in this subject? > > Is there any worthwhile outcome which could be the base for someone > else to continue and complete the work? > > Are there any plans to add CPDB support independent of Tanmay? > > Problems are the following: > > > 1. If there is an IPP printer available CUPS would create a temporary > queue as soon as you try to print on such a printer. See the output of > > lpstat -l -e > > for such queues. On my machine I get > > till@till-x1yoga:~/Downloads$ lpstat -l -e > HP_OfficeJet_Pro_8730_08C229_ network none > ipps://HP%20OfficeJet%20Pro%208730%20%5B08C229%5D._ipps._tcp.local/ > HP_OfficeJet_Pro_8730_08C229_USB_ network none > ipp://HP%20OfficeJet%20Pro%208730%20%5B08C229%5D%20(USB)._ipp._tcp.local/ > Label_Printer network none ipps://Label%20Printer._ipps._tcp.local/ > Office_Printer network none ipps://Office%20Printer._ipps._tcp.local/ > snap-ps permanent ipp://localhost/printers/snap-ps > ipp://HP%20OfficeJet%20Pro%208730%20%5B08C229%5D._ipp._tcp.local/ > snap_ps_till_x1yoga network none > ipps://snap-ps%20%40%20till-x1yoga._ipps._tcp.local/cups > till@till-x1yoga:~/Downloads$ > > The ones with "permanent" a standard CUPS queues which the print > dialog happily lists. The one with "network" CUPS would only create > on-demand. These are not listed by the print dialog and should be > listed. Michael Sweet has made a new (already years ago) CUPS API for > that, using the cupsEnumDests() functions. From my testing, print dialog shows even network printers, if they are advertised by Avahi. Unfortunately, the current GTK print backend only lists a permanent ones and depends on Avahi on the network ones. I concur this should be fixed and using CUPS newer API would do the trick, which I mention in https://bugzilla.redhat.com/show_bug.cgi?id=1784449 . > > > > 2. The GTK print dialog seems to list IPP printers diectly from > DNS-SD, these even show if no CUPS daemon at all is running on the > system, suggesting that the dialog prints spooler-less to these > printers, and as many of these do not spool by themselves one can > expect the application to hang (if the GTK dialog has no mini spooler > built in). Queue names seem to be constructed from the DNS-SD service > name. If I understand correctly the problem is about 'don't print without CUPS or it can cause problems'. Thank you for pointing it out! I guess using CUPS API can solve those too. > > 3. I have tried to print on such independent-of-CUPS IPP printers and > ran into two problems: > > a. One printer comes from the sample Printer Application from the > PAPPL project. It does not accept PDF input, only Raster formats. > The dialog seems to happily send PDF jobs to this printer (which > get aborted by the Printer Application). So before listing > arbitrary DNS-SD-reported IPP printers, the TXT record of the > printer needs to get checked and whether in its "pdls" entry PDF > (or the job's format) is listed. Only then the printer can be > listed. I haven't tested PAPPL based printer application yet, I hope I'll get into it this year. Thank you for trying them out, Till! > b. I have a physical IPP network printer which does driverless IPP > printing. It advertises itself by DNS-SD (and so the dialog always > lists it, also without CUPS running), understands PDF, and you get > all needed properties of the printer if you send a get-printer- > attributes IPP request to it. This allows me driverless printing > with CUPS. The GTK dialog seems to be sending something else than > a get-printer-attributes IPP request to the printer, as when I > select the printer in the dialog, the dialog never completes > getting the printer's properties. The "Print" stays permanently > grayed and the status stays permanently on "Getting Printer > Information". > Actually, regarding the testing I've done, the issue you mention here is probably connected to your network topology and how GTK works with DNS-SD advertised printers. I have the same problem with my printer at home. The printer is behind a router, capable of driverless printing and found by Avahi, but I'm not capable to print via DNS-SD based queue in GTK. But when I tried printing within my local network in the office, I was able to print via DNS-SD based queue in GTK if the printer was connected within local network (probably without router). Originally, https://bugzilla.redhat.com/show_bug.cgi?id=1784449 was about the issue you mentioned. > > > GTK dialog backends on the system are the following: > > ill@till-x1yoga:~/Downloads$ ls > /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/ > libprintbackend-cloudprint.so libprintbackend-file.so > libprintbackend-test.so > libprintbackend-cups.so libprintbackend-lpr.so > till@till-x1yoga:~/Downloads$ dpkg -S > /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/* > libgtk-3-0:amd64: > /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-cloudprint.so > libgtk-3-0:amd64: > /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-cups.so > libgtk-3-0:amd64: > /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-file.so > libgtk-3-0:amd64: > /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-lpr.so > libgtk-3-0:amd64: > /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/libprintbackend-test.so > till@till-x1yoga:~/Downloads$ > > Everything coming from my Ubuntu 20.04, no experiments performed, no > student's code tried out here. > > > I assume that all these problems originate in the > libprintbackend-cups.so module. > > > So my suggestion is to get CPDB support into the GTK dialog. > > How should we proceed here? Rithvik, would you perhaps volunteer or at > least in some form help? IMO any help is welcome :) - Rithvik, if you are willing, you can join us at https://bugzilla.redhat.com/show_bug.cgi?id=1784449 . Probably we will elevate the issue to gtk gitlab in the future, but we talk about the issue in the bugzilla ticket at the moment. Hope you all are well and have a nice day, Zdenek > Till > _______________________________________________ > Printing-architecture mailing list > Printing-architecture@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems 2020-07-29 5:24 ` Zdenek Dohnal @ 2020-07-29 12:07 ` Till Kamppeter 2020-07-29 12:54 ` Zdenek Dohnal 0 siblings, 1 reply; 8+ messages in thread From: Till Kamppeter @ 2020-07-29 12:07 UTC (permalink / raw) To: Zdenek Dohnal, Marek Kasik Cc: Aveek Basu, Open Printing, Rithvik Patibandla, Rithvik Patibandla On 29/07/2020 07:24, Zdenek Dohnal wrote: > Hi Till, > > I and Marek are working on the most of issues you mentioned here > https://bugzilla.redhat.com/show_bug.cgi?id=1784449 , but I didn't > propose cpdb support for it, because I wasn't sure of readiness of the > project after GSoC. IIRC Ubuntu doesn't ship cpdb either and you mention > the person who should oversee the project is unresponsive, so it would > need time to learn about the project and probably make some changes to > get it into GTK - I'm not sure whether implementing the current CUPS API > wouldn't be faster. > CPDB, the core of it was already developed 3 years ago in GSoC 2017 and it is working. After that we struggled on getting GSoC students to implement it in GTK and Qt. In LibreOffice it got already implemented back in 2017. It is not used in Ubuntu because there is no implementation for the GTK and Qt print dialogs, which are the dialogs most applications use. Probably implementing the current CUPS API could be easier, but if there are further chabges on the printing architecture the GTK dialog, especially with the long feature release cycles of GNOME/GTK, will quickly be behind again. The CPDB CUPS backend we would quickly update if new CUPS versions require it, making ALL print dialogs up-to-date again at once. > From my testing, print dialog shows even network printers, if they are > advertised by Avahi. Unfortunately, the current GTK print backend only > lists a permanent ones and depends on Avahi on the network ones. > Yes, the new CUPS API is the solution, showing exactly what the user wants. The CPDB CUPS backend actually uses the new CUPS API. It is much more complex and error-prone to stick with the old CUPS API and to work around by directly using the Avahi responses of the network printers. The new CUPS API already provides correct queue names, filters out unsuitable IPP printers, polls the printers correctly in all network architectures, it is assured that printing goes through CUPS, ... > I concur this should be fixed and using CUPS newer API would do the > trick, which I mention in > https://bugzilla.redhat.com/show_bug.cgi?id=1784449 . > Yes, the bug report shows exactly what I have observed and simply using the new CUPS API (preferably through CPDB) would solve everything. > > If I understand correctly the problem is about 'don't print without CUPS > or it can cause problems'. Thank you for pointing it out! > Yes, CUPS does not only list printers, it - is a spooler, you send a job, it stores it in a file, in a print queue and the print-job function returns, so you can go on working in your app before printing finishes. - it converts the input file format in what is needed for printing. For this it calls one or more of the filters provided by cups-filters. Most printers, including modern driverless IPP obes, do not understand PDF, but jobs come in PDF, so they need to get converted. Therefore you should print ALWAYS through CUPS and the print dialog should assure this. Print-to-file and Google Cloud Print naturally work without CUPS, but printing on physical printers should always be done through CUPS. > I guess using CUPS API can solve those too. Yes, if you list printers and options, and alsoset options and print, all through the new CUPS API, printing through CUPS is assured. > I haven't tested PAPPL based printer application yet, I hope I'll get > into it this year. Thank you for trying them out, Till! > PAPPL (https://github.com/michaelrsweet/pappl/) is a library containing everything needed to create Printer Applications. Printer Applications are daemons which emulate an IPP network printer on localhost. They conform completely with IPP and do everything which an IPP network printer does (in the future also what an IPP multi-function device does): Advertising themselves via DNS-SD, answering get-printer-attributes IPP requests with their capabilities, printing, scanning, faxing, and even providing an admin web interface. Printer Applications replace classic printer drivers consisting of filters and PPD files. Once because PostScript and PPDs is obsolete, second that for CUPS all printers are driverless IPP printers and so CUPS does not need to muck around with drivers any more, and third, CUPS and the driver are connected by IP communication, not by dropping files into reserved directories, this allows to put CUPS, the drivers, and office applications into independent sandboxed packages, especially the sandboxed packages of Printer Applications are an OS-distribution-independent way to package drivers. IPP printers, including Printer Applications, are not required to spool jobs, nor are they required to understand PDF (the standards should also work out on cheap printers, and, indeed, the cheapest 50-EUR network printers do driverless IPP). Due to this a print dialog getting the job data as PDF from the application would choke on printing directly to an arbitrary IPP printer, which we see when we try to print to the demo Printer Application which comes with PAPPL. This Printer Application only accepts Raster formats but not PDF as input. By the way, PAPPL makes it very easy tocreate Printer Applicatons. Here is an example for a PCL (HP LaserJet) one: https://github.com/michaelrsweet/hp-printer-app/ >> The "Print" stays permanently >> grayed and the status stays permanently on "Getting Printer >> Information". >> > Actually, regarding the testing I've done, the issue you mention here is > probably connected to your network topology and how GTK works with > DNS-SD advertised printers. > > I have the same problem with my printer at home. The printer is behind a > router, capable of driverless printing and found by Avahi, but I'm not > capable to print via DNS-SD based queue in GTK. > > But when I tried printing within my local network in the office, I was > able to print via DNS-SD based queue in GTK if the printer was connected > within local network (probably without router). > > Originally, https://bugzilla.redhat.com/show_bug.cgi?id=1784449 was > about the issue you mentioned. > My network topology is very simple: I have a single router connecting to the internet and everything, especially my printer and my laptop, is behind the router. This also means that my printer and my laptop have no router between them. In addition, the problem does not only occur when connecting to my printer via the network but also via IPP-over-USB using https://github.com/OpenPrinting/ipp-usb And independent of this I can poll the capabilities of my printer with a simple get-printer-attributes IPP request, issued by ipptool, by the driverless utility of cups-filters, or by cups-browsed, both via network and via IPP-over-USB. So the problem must be in the print dialog, doing something weird instead of the simple get-printer-attributes IPP request (Perhaps using CUPS API on IPP network printer? Trying to grab print queue PPD from an IPP network printer?). By the way, cups-browsed cannot be in the way as I have turned it off. Hope we will be able to switch to CPDB soon. Till ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems 2020-07-29 12:07 ` Till Kamppeter @ 2020-07-29 12:54 ` Zdenek Dohnal 2020-07-29 13:46 ` Till Kamppeter 0 siblings, 1 reply; 8+ messages in thread From: Zdenek Dohnal @ 2020-07-29 12:54 UTC (permalink / raw) To: Till Kamppeter, Marek Kasik Cc: Aveek Basu, Open Printing, Rithvik Patibandla, Rithvik Patibandla [-- Attachment #1.1: Type: text/plain, Size: 5247 bytes --] On 7/29/20 2:07 PM, Till Kamppeter wrote: > > Yes, CUPS does not only list printers, it Yes, thank you for explanation - I mentioned only listing because your problem was about listing. > > Therefore you should print ALWAYS through CUPS and the print dialog > should assure this. Print-to-file and Google Cloud Print naturally > work without CUPS, but printing on physical printers should always be > done through CUPS. > I concur. > I haven't tested PAPPL based printer application yet, I hope I'll get >> into it this year. Thank you for trying them out, Till! >> > > PAPPL (https://github.com/michaelrsweet/pappl/) is a library > containing everything needed to create Printer Applications. Printer > Applications are daemons which emulate an IPP network printer on > localhost. They conform completely with IPP and do everything which an > IPP network printer does (in the future also what an IPP > multi-function device does): Advertising themselves via DNS-SD, > answering get-printer-attributes IPP requests with their capabilities, > printing, scanning, faxing, and even providing an admin web interface. > > Printer Applications replace classic printer drivers consisting of > filters and PPD files. Once because PostScript and PPDs is obsolete, > second that for CUPS all printers are driverless IPP printers and so > CUPS does not need to muck around with drivers any more, and third, > CUPS and the driver are connected by IP communication, not by dropping > files into reserved directories, this allows to put CUPS, the drivers, > and office applications into independent sandboxed packages, > especially the sandboxed packages of Printer Applications are an > OS-distribution-independent way to package drivers. Thank you for a detailed explanation! I regularly check meeting minutes from openprinting meetups and attend PWG meetup once a year, so I have a basic knowledge, but it is always good to repeat and I can miss something. I just haven't had PAPPL and any PAPPL created printer application in my hands to try how it works - I only saw Mike's workshop at PWG meetup in April. > > IPP printers, including Printer Applications, are not required to > spool jobs, nor are they required to understand PDF (the standards > should also work out on cheap printers, and, indeed, the cheapest > 50-EUR network printers do driverless IPP). > > Due to this a print dialog getting the job data as PDF from the > application would choke on printing directly to an arbitrary IPP > printer, which we see when we try to print to the demo Printer > Application which comes with PAPPL. This Printer Application only > accepts Raster formats but not PDF as input. > > By the way, PAPPL makes it very easy tocreate Printer Applicatons. > Here is an example for a PCL (HP LaserJet) one: > > https://github.com/michaelrsweet/hp-printer-app/ Thanks, I'll check it. > >>> The "Print" stays permanently >>> grayed and the status stays permanently on "Getting Printer >>> Information". >>> >> Actually, regarding the testing I've done, the issue you mention here is >> probably connected to your network topology and how GTK works with >> DNS-SD advertised printers. >> >> I have the same problem with my printer at home. The printer is behind a >> router, capable of driverless printing and found by Avahi, but I'm not >> capable to print via DNS-SD based queue in GTK. >> >> But when I tried printing within my local network in the office, I was >> able to print via DNS-SD based queue in GTK if the printer was connected >> within local network (probably without router). >> >> Originally, https://bugzilla.redhat.com/show_bug.cgi?id=1784449 was >> about the issue you mentioned. >> > > My network topology is very simple: I have a single router connecting > to the internet and everything, especially my printer and my laptop, > is behind the router. This also means that my printer and my laptop > have no router between them. In addition, the problem does not only > occur when connecting to my printer via the network but also via > IPP-over-USB using > > https://github.com/OpenPrinting/ipp-usb > > And independent of this I can poll the capabilities of my printer with > a simple get-printer-attributes IPP request, issued by ipptool, by the > driverless utility of cups-filters, or by cups-browsed, both via > network and via IPP-over-USB. So the problem must be in the print > dialog, doing something weird instead of the simple > get-printer-attributes IPP request (Perhaps using CUPS API on IPP > network printer? Trying to grab print queue PPD from an IPP network > printer?). > > By the way, cups-browsed cannot be in the way as I have turned it off. Then how would you explain printing from GTK works for some cases via DNS-SD based queue as it worked in our office? If it didn't work completely, it would be more tickets about the issue. I cannot test it right now in the office for an obvious reasons, but IIRC cups-browsed was turned off too. > > Hope we will be able to switch to CPDB soon. > > Till > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems 2020-07-29 12:54 ` Zdenek Dohnal @ 2020-07-29 13:46 ` Till Kamppeter [not found] ` <81d778b8-a608-032c-9c59-88c12984f3b5@redhat.com> 0 siblings, 1 reply; 8+ messages in thread From: Till Kamppeter @ 2020-07-29 13:46 UTC (permalink / raw) To: Zdenek Dohnal, Marek Kasik Cc: Aveek Basu, Open Printing, Rithvik Patibandla, Rithvik Patibandla On 29/07/2020 14:54, Zdenek Dohnal wrote: > Then how would you explain printing from GTK works for some cases via > DNS-SD based queue as it worked in our office? If it didn't work > completely, it would be more tickets about the issue. This is really strange for me, too, especially that I can access my printer correctly when not using the GTK dialog. Marek, when the dialog discovers an IPP network printer via DNS-SD/Avahi, without using CUPS, how does the dialog then poll the printer's capability information? Is it directly doing a get-printer-attributes IPP request? Which URI is it using and which arguments ("all", "media-col-database", ...)? Or is it using some API function of CUPS? Till ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <81d778b8-a608-032c-9c59-88c12984f3b5@redhat.com>]
* Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems [not found] ` <81d778b8-a608-032c-9c59-88c12984f3b5@redhat.com> @ 2020-07-29 16:13 ` Till Kamppeter 0 siblings, 0 replies; 8+ messages in thread From: Till Kamppeter @ 2020-07-29 16:13 UTC (permalink / raw) To: Marek Kasik, Zdenek Dohnal Cc: Aveek Basu, Open Printing, Rithvik Patibandla, Rithvik Patibandla On 29/07/2020 17:35, Marek Kasik wrote: > > Yes, it does an IPP request on the printer for these attributes: > > "printer-name", > "printer-uri-supported", > "member-uris", > "printer-location", > "printer-info", > "printer-state-message", > "printer-state-reasons", > "printer-state", > "queued-job-count", > "printer-is-accepting-jobs", > "job-sheets-supported", > "job-sheets-default", > "printer-type", > "auth-info-required", > "number-up-default", > "ipp-versions-supported", > "multiple-document-handling-supported", > "copies-supported", > "number-up-supported", > "media-col-default", > "media-col-supported", > "media-default", > "media-size-supported", > "media-supported", > "media-left-margin-supported", > "media-right-margin-supported", > "media-bottom-margin-supported", > "media-top-margin-supported", > "sides-default", > "sides-supported", > "output-bin-default", > "output-bin-supported" > You could simply try "all" and "media-col-database", this is what /usr/share/cups/ipptool/get-printer-attributes-2.0.test does. This is also what I do in libcupsfilters so that "driverless" and cups-browsed can create PPDs. > Gtk has its own http-based facility to handle IPP requests so it does > not call CUPS API for this. Why that, is it not easier to simply use libcups? What is the specialty of this code and where is it located in the source code of GTK? > The URI is composed of protocol, address, port and resource path of the > discovered printer now. > OK, should be correct. Please compare with CUPS output ("lpstat -l -e", "lpinfo -l -v"). > However, for the temporary queues there is an issue. How to get names > and URIs of those printers without calling the cupsEnumDests()? I can > emulate the way the CUPS creates them from the Avahi data but it would > be better to get those via an IPP operation. You probably mean the CUPS URIs to talk to the temporary CUPS queues, as the device URIs of the physical printers are derivable from the DNS-SD record (protocol://host:port/TXT-"rp"-field). The CUPS URI is always ipp(s)://cups-host:cups-port/printers/queue-name. So you have to find the correct queue name here, which would match the output of "lpstat -e". Best is to check through the source code of CUPS, this is what I do in such cases, but AFAIK it is the DNS-SD service name with each group of non-alphanumeric characters replaced by a single '_', no change in upper/lower case and no removal of a trailing underscore (Michael, am I right? Which function in the CUPS source does this?). Till ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <e3c06595-f150-02e6-5d44-f7565a620b3c@redhat.com>]
* Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems [not found] ` <e3c06595-f150-02e6-5d44-f7565a620b3c@redhat.com> @ 2020-07-29 15:43 ` Till Kamppeter 0 siblings, 0 replies; 8+ messages in thread From: Till Kamppeter @ 2020-07-29 15:43 UTC (permalink / raw) To: Marek Kasik Cc: Aveek Basu, Open Printing, Rithvik Patibandla, Rithvik Patibandla On 29/07/2020 17:10, Marek Kasik wrote: > You've seen all the communication I had with him this year. He hasn't > sent me a code which would compile. > I did not realize that it was so bad. Before I put him with some other mentor to do CPDB he did a good job on filters for me. There are students whose imagination of programming is typing code without ever trying to build and run it, but I did not know that he was like that. >> Is there any worthwhile outcome which could be the base for someone >> else to continue and complete the work? >> >> Are there any plans to add CPDB support independent of Tanmay? > I don't have a plan to integrate CPDB in Gtk now. I plan to implement > the temporary queues support there. > No problem, if you get the dialog working correctly with the new CUPS API it would be great. As the dialog has easy-to-dro-in backend modules, we can find someone writing such a module and testing it, and post it as a Feature Request when it is ready. > It would be good to have an IPP operation defined for cupsEnumDests() in > CUPS. We have a good mechanism which handles these in non-blocking manner. > So you do not want to use the new CUPS API because it is not asynchronous? I think one could help oneself creating asynchronous wrapper functions. AFAIR CPDB wraps it asynchronously. You can can start an asynchronous printer list process with CPDB and while the dialog is open and active the printer entries from all CPDB backends, including the one for the new CUPS API, are rolling in. > This is because I've implemented it in 2013 and the local queues were > added to CUPS at 2016. What were the options at that time? > I've implemented it so that it worked with the printer from you, the HP > CP3525. It also worked with CUPS published printers. > There were some bugs over the years but I've tried to fix most of them. > Unfortunately I've got a printer which claims IPP capability but I'm not > able to print on it over ipptool, this makes me think that I could try > the local queue feature of CUPS. > > As CUPS has this local queue feature, and it is actually working, you should use it in the print dialog, using the new CUPS API. Ideally, if CUPS adds a new feature, print dialogs should updated to support it. If you think the CUPS development pace is too fast for keeping up with it in GTK, simply add CPDB support and we from OpenPrinting will care of the rest. It would be great if I do not need to supply cups-browsed as a daemon to retro-fit the GTK print dialog with modern CUPS by the daemon providing the old interface. I would love to have Ubuntu shipping with cups-browsed not running by default. And please do not make the GTK print dialog bypass CUPS when printing on IPP printers. > This was a bug I think I've fixed at the end of 2019. > >> GTK dialog backends on the system are the following: > > What gtk3 version is this? Version 3.24.20 If this does not contain the fix, can you tell me which GIT commits have to be added as distro patch? till@till-x1yoga:~/Downloads$ dpkg -l libgtk-3-0:amd64 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-================-================-============-============================> ii libgtk-3-0:amd64 3.24.20-0ubuntu1 amd64 GTK graphical user interface> till@till-x1yoga:~/Downloads$ Till ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <CA+tVraiqkkoKRaO8Pe8HOzJpi4FD=PC1-wCHacQ6L-Tht934Lg@mail.gmail.com>]
* Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems [not found] ` <CA+tVraiqkkoKRaO8Pe8HOzJpi4FD=PC1-wCHacQ6L-Tht934Lg@mail.gmail.com> @ 2020-07-29 19:32 ` Till Kamppeter 0 siblings, 0 replies; 8+ messages in thread From: Till Kamppeter @ 2020-07-29 19:32 UTC (permalink / raw) To: Rithvik Patibandla Cc: Aveek Basu, Open Printing, Marek Kasik, Rithvik Patibandla On 29/07/2020 05:08, Rithvik Patibandla wrote: > Hi Till, > > I'm not completely sure of the current status of the work or what the > expected end product is, but if you think I can take it up and complete > it, I'd definitely like to do it. > > However, I'm working as a full time developer so I can only spend about > 10-15 hrs per week on this, I hope that'll be sufficient. No problem should not be such a big deal. Rithvik, as you have already worked with CPDB you will probably get wasily into this project. The need of this work you can derive from this thread. The starting point is the following. If you have the current Ubuntu (20.04) installed, you have the following directory: till@till-x1yoga:~/Downloads$ ls /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/printbackends/ libprintbackend-cloudprint.so libprintbackend-file.so libprintbackend-test.so libprintbackend-cups.so libprintbackend-lpr.so till@till-x1yoga:~/Downloads$ These are the backends with which the GTK print dialog communicates with the different print technologies. These backends are specific to the GTK dialog, and also only found in that directory, in contrary to the CPDB which are found via D-Bus (snappable) and supposed to work with all GUI toolkits. The idea is to replace all these GTK print dialog backends by one CPDB adapter backend, let us call it libprintbackend-cpdb.so. It is supposed to be dropped into this directory and all the other libprintbackend-*.so removed. libprintbackend-cpdb.so is supposed to be a backend for the GTK print dialog and a frontend for the CPDB backends. Its task is to relay the calls for listing printers, listing options, setting options, sending jobs, ... to the CPDB backends. This way the GTK print dialog gets its content from the CPDB and not from its own backends. Note that the GTK dialog does asynchronous listing of the printers, it seems to call all its backend to listen for printers and adds printers to the list when they are discovered, with the dialog already interactive, so the user can select the desired printers as soon as it shows up and does not need to wait for the list to complete. So also no timeout for the listing process is required. CPDB works this way, too. So integration seems to be easy. Use Nilanjana's demo text mode frontend which comes with the cpdb-libs package as example. We would appreciate if you could take up this task. Till ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-07-29 19:32 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-28 22:33 [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems Till Kamppeter 2020-07-29 5:24 ` Zdenek Dohnal 2020-07-29 12:07 ` Till Kamppeter 2020-07-29 12:54 ` Zdenek Dohnal 2020-07-29 13:46 ` Till Kamppeter [not found] ` <81d778b8-a608-032c-9c59-88c12984f3b5@redhat.com> 2020-07-29 16:13 ` Till Kamppeter [not found] ` <e3c06595-f150-02e6-5d44-f7565a620b3c@redhat.com> 2020-07-29 15:43 ` Till Kamppeter [not found] ` <CA+tVraiqkkoKRaO8Pe8HOzJpi4FD=PC1-wCHacQ6L-Tht934Lg@mail.gmail.com> 2020-07-29 19:32 ` Till Kamppeter
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.