* [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
* 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
* 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
* 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.