[Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Till Kamppeter]

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

Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Zdenek Dohnal]

[-- 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 --]

Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Till Kamppeter]

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

Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Zdenek Dohnal]

[-- 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 --]

Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Till Kamppeter]

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

Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Till Kamppeter]

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

Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Till Kamppeter]

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

Re: [Printing-architecture] GTK Print Dialog: Modern IPP printing environments cause problems

[Till Kamppeter]

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