Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > If all you want to do is prevent CUPS from auto-discovering > remote printers, edit /etc/cups/cupsd.conf and set 'Browsing Off' "Browsing" is documented as "Specifies whether shared printers are advertised". That sounds like printers on this host are advertised to other hosts on the network, but if that's what the parameter does, then "Browsing" is a misleading name for it. Is it supposed to mean that printers shared by other hosts are "advertised" in print dialogs on this host? That would be a very strange use of both "shared" and "advertised", but would agree better with "Browsing". It also looks like "Browsing" is redundant with "BrowseLocalProtocols", which is documented as "Specifies which protocols to use for local printer sharing". For any reasonable reading of the manual, "BrowseLocalProtocols none" should have the same effect as "Browsing No". It seems safest to turn off both, but I'm not at all sure whether that prevents network printers from showing up in my print dialogs. Björn Persson pgp6atBpTr1Cr.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
the assumption that all of those several million
people will want to print from anything with a CPU ("whatever computing
devices one uses") or that that is even the common case.
There's been no assumption that "all" want any-one-thing.
As for common, print-from-any-device-you-use is common here, with ~ 1K
'in-house' users, and easily-dozens-per-day of 'guests'.
That's FAR more common than your 'objection' to it.
As has been said repeatedly here -- paraphrasing, "different strokes for different
folks".
If the developers think its important to support their user-base, what are you
objecting to?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Stephen John Smoogen wrote:
> On Mon, 24 May 2021 at 22:30, Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Solomon Peachy wrote:
>>
>> > On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote:
>> >> I do not see how that is the common use case. Why would I want to
>> >> print from my telephone? I do not even normally print from my
>> >> notebook!
>> >
>> > I don't think it's controversial to say that one needs to print from
>> > whatever computing devices one uses.
>>
>> If I am sitting next to my printer, I have a desktop computer in front of
>> me
>> from which I can issue the print job, so why would I want to do it from a
>> notebook or smartphone?
>>
> Kevin. No one is saying YOU want to print from your phone. However this
> software is not written just for you. Solomon and others do not write the
> software just for you but for the several million people who have to use
> printers in all different kinds of environments.
What I am objecting to is the assumption that all of those several million
people will want to print from anything with a CPU ("whatever computing
devices one uses") or that that is even the common case.
Of course, if all you have is a smartphone, then you will want to print from
it. But that is not going to be the central use case for Fedora (even though
it may be a niche use case for those running Fedora on the PinePhone ;-) ).
> For a good proportion of those people out there.. printing from the phone
> is an expected feature be it instagram memes or that pdf your department
> head sent out which is too small to read on the phone.
Sent out per e-mail? Then you fire up your desktop e-mail client (on your
desktop or notebook) and print from there.
> So it is going to be something Solomon and others will focus on or they
> might as well scrap printing.
That is quite a strong wording.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 4:47 PM, Solomon Peachy wrote: But disabling mDNS altogether might cause undesired regerssions elsewhere. Sure. Particularly if you don't set up your /etc/nsswitch.conf correctly. Hence the 'YMMV'. In general, we assume zero-trust and avoid enabling auto-anything. We add trust and loosen constraints, cautiously, when said 'regressions elsewhere' absolutely demand it. Avoids the 'fun' of accidentally exposing a printer queue in the CEOs office ;-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Wed, May 26, 2021 at 04:41:27PM -0400, PGNet Dev wrote: > On 5/26/21 4:28 PM, Björn Persson wrote: > > > You have always had (and always will) have that choice; the ability to > > > disable automatic printer discovery has been present since discovery was > > > added with CUPS 1.2 (released back in 2006!) > > > > I'll have to see if I can find that option. Thanks for the hint. > > fyi, also useful, > > man cups-browsed > > here, I > > systemctl disable cups-browsed > systemctl disable avahi-daemon > > setup printers @ dhcp/dns explicitly, and avoid autodiscovery 'surprises' > altogether. cups-browsed isn't enabled by default, FWIW. But disabling mDNS altogether might cause undesired regerssions elsewhere. If all you want to do is prevent CUPS from auto-discovering remote printers, edit /etc/cups/cupsd.conf and set 'Browsing Off' - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 4:28 PM, Björn Persson wrote: You have always had (and always will) have that choice; the ability to disable automatic printer discovery has been present since discovery was added with CUPS 1.2 (released back in 2006!) I'll have to see if I can find that option. Thanks for the hint. fyi, also useful, man cups-browsed here, I systemctl disable cups-browsed systemctl disable avahi-daemon setup printers @ dhcp/dns explicitly, and avoid autodiscovery 'surprises' altogether. ymmv. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On Wed, May 26, 2021 at 08:15:46PM +0200, Björn Persson wrote: > > And I always try to avoid using protocols that assume that the local > > link is secure. That's one of the reasons why my printer is connected by > > USB, and I would like to continue to have that choice. > > You have always had (and always will) have that choice; the ability to > disable automatic printer discovery has been present since discovery was > added with CUPS 1.2 (released back in 2006!) I'll have to see if I can find that option. Thanks for the hint. Björn Persson pgpLUW8ag8A8D.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Wed, May 26, 2021 at 08:15:46PM +0200, Björn Persson wrote: > And I always try to avoid using protocols that assume that the local > link is secure. That's one of the reasons why my printer is connected by > USB, and I would like to continue to have that choice. You have always had (and always will) have that choice; the ability to disable automatic printer discovery has been present since discovery was added with CUPS 1.2 (released back in 2006!) But there is no way to tell from a stock OS print dialog if a given printer identifier is local, remote, "secure", "hostile" or whatever. There never has been, and I don't think there ever can be. You want secure printing? Put the document you want to print onto a USB stick, and plug it into an airgapped printer that is in a controlled-access room. Even that's not necessarily sufficient, but anything _less_ than that is clearly insecure and inherently untrustable. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Stephen John Smoogen wrote: > The truth is that most people know about it, and have decided that they can > go 'meh' and keep living. I am well aware that most people don't think for a second about computer security. I see examples every day. They tend to begin caring after they find out that they personally have been owned. So your argument is that programs should be written insecurely to make the few who care as insecure as the majority? I shouldn't even have the option to care about security? Otherwise I don't see how what you wrote is an argument in this debate. > Instead IPP, LPD and other > print protocols have always been written with the assumption that the local > network is some level of secure. And I always try to avoid using protocols that assume that the local link is secure. That's one of the reasons why my printer is connected by USB, and I would like to continue to have that choice. Björn Persson pgp2GJIq_HFQB.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > Those that do appear show up as "queuename at host" or > "mfg_model_hostname" I can trust that they always contain either the string " at " or two underscores? Or is that just what well-behaved printers do, while an attacker can name their fake printer however they want? > (for native IPP printers, there's usually a partial > MAC address in there by default too) Security has no use for "usually". > Queues you create > manually/permanently can be called whatever you want and point wherever > you want. So if I see a print queue whose name contains neither the word "at" nor any underscores, is that a guarantee that it's a manually configured queue? In that case I may be able to keep my configured queue and know that I'm sending to my USB printer (or, I guess, redo the configuration when I'm forced to wrap a web server around the USB printer). But the existence of two different naming schemes makes me suspect that there is no such guarantee. I thought for a while that I could configure an unguessable queue name to let me distinguish between my own print queue and the attacker's, but that won't work. A DNS rebinding attack would let the attacker read the queue name from CUPS' web interface, so I can't rely on the queue name being secret. > CUPS's auto-discovery mechanisms have _always_ assumed the > local network can be trusted. You mean CUPS _already_ allows an attacker on the local link to impersonate my USB printer, even before it starts wrapping web servers around USB printers? That's disappointing, but at this point I'm quite ready to believe it. > Sure, someone could be spoofing a specific printer name/identifier just > so they can capture a document *you* want to print, but if there's that > level of persistant hostile presence on your local network, you're > already completly screwed. I would be if I would use insecure protocols on that network – but I stopped using Telnet, SMB and FTP at home decades ago. Björn Persson pgpeiVdE4m7Yl.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/26/21 7:05 AM, Zdenek Dohnal wrote: Hi Robert, On 5/24/21 2:39 PM, Robert Marcano via devel wrote: On 5/24/21 3:29 AM, Zdenek Dohnal wrote: Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. This application will advertise the device on localhost via MDNS protocol and will communicate with CUPS via IPP, both public well-known protocols. The only place where the data can turn into proprietary is filtering, but it's the same with printer drivers. -- Greetings, Is there any plan to support these IPP printer applications over Unix domain sockets? pappl supports listening on domain sockets (IIUC the docs https://www.msweet.org/pappl/pappl.html), so if a printer application decides on it will use domain sockets, it is possible. Thanks for the information. Last time I saw some reluctance from CUPS maintainers (before the fork) to add domain sockets support for IPP, that was the reason I asked. If pappl can do it now I presume CUPS will be able to use these printers. I manage a virtual printer that uses CUPS filters and backends to capture documents to an application database. We have been using CUPS authentication features to control who can use the printer, and not to have to reimplement authentication on the filter and backends. With network bound IPP applications, anyone on the same multiuser machine would be able to bypass CUPS and send documents directly unless I duplicate CUPS authentication functionality. Unix sockets would help with that, ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Robert, On 5/24/21 2:39 PM, Robert Marcano via devel wrote: > On 5/24/21 3:29 AM, Zdenek Dohnal wrote: >> >> Devices which currently depend on a deprecated functionality - >> printer drivers and raw queues - will need a printer application once >> the deprecated functionality is removed from CUPS. This application >> will advertise the device on localhost via MDNS protocol and will >> communicate with CUPS via IPP, both public well-known protocols. The >> only place where the data can turn into proprietary is filtering, but >> it's the same with printer drivers. >> >> -- > > Greetings, Is there any plan to support these IPP printer applications > over Unix domain sockets? pappl supports listening on domain sockets (IIUC the docs https://www.msweet.org/pappl/pappl.html), so if a printer application decides on it will use domain sockets, it is possible. > > I manage a virtual printer that uses CUPS filters and backends to > capture documents to an application database. We have been using CUPS > authentication features to control who can use the printer, and not to > have to reimplement authentication on the filter and backends. With > network bound IPP applications, anyone on the same multiuser machine > would be able to bypass CUPS and send documents directly unless I > duplicate CUPS authentication functionality. Unix sockets would help > with that, > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Przemek, thank you for trying the driverless and the investigation! Would you mind checking if the similar bug isn't already reported on Avahi in Fedora and reporting it if not? Maybe Avahi maintainers can point out what is the best for debugging Avahi. I recommend setting debug logging on avahi-daemon service file, maybe its logs will show something more. On 5/25/21 8:20 PM, przemek klosowski via devel wrote: > > There are so many moving pieces here that it's hard to get a handle on > this. I had trouble seeing local network printers so I tried following > the advice Zdenek published [1], but I ran into a nest of issues: > printing depending on avahi, which fails quietly and is hard to debug. > > Specifically, I did *avahi-browse -avrt* which just returns with > avahi_service_browser_new() failed: Invalid service type > > This seems to be related to a bug where some devices are sending > non-compliant data to avahi: > https://github.com/lathiat/avahi/issues/212 but we're already far away > from the print subsystem.. I tried running avahi-browser under gdb but > between the missing and not-autoloading debuginfo packages, and the > callback-style structure, I wasn't able to catch it receiving the data > that causes the problem. > > I guess my point here is that we have a complex, interdependent > system, and when it fails, it is fairly opaque. At this point I am not > sure what to do: is the root cause here the avahi bug? I am willing to > spend the effort getting to the bottom of it but I can't figure out > where to start. > IIUC the upstream issue, the core of the problem is that something in your local network sends a broken PTR record which avahi cannot cope with and it breaks avahi-browse in whole LAN... > > > >> On 5/24/21 1:42 PM, Stephen John Smoogen wrote: >>> I have had very bad luck in setting up new network printers over the >>> last 4 years. I can get all of them to print from Windows and Mac, >>> but every one of them from HP, Brother, and some other brands could >>> not print anything from Linux. They were all 'Linux ready' but were >>> doing it via either Google Print or a set of proprietary software >>> blobs to be put on the computer. [They even came with ipp filters >>> but they called the blobs]. I have a Brother MFC-27100W in my office >>> which I print to via my wife's Mac because of this. >>> >> >> I have written some basic info about how to find out whether your >> printer supports driverless [1] and how to setup it [2]. If you have >> at least F33 and have the device in your LAN, you can use temp queues >> for sure, otherwise you need to create a permanent queue via lpadmin: >> >> $ lpadmin -p -v -m >> everywhere -E >> >> >> If you still experience the issue, do feel free to file a bug for >> cups in bugzilla and I can look into it further. >> >> >> [1] >> https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F >> >> [2] >> https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer >> >> > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
There are so many moving pieces here that it's hard to get a handle on this. I had trouble seeing local network printers so I tried following the advice Zdenek published [1], but I ran into a nest of issues: printing depending on avahi, which fails quietly and is hard to debug. Specifically, I did *avahi-browse -avrt* which just returns with avahi_service_browser_new() failed: Invalid service type This seems to be related to a bug where some devices are sending non-compliant data to avahi: https://github.com/lathiat/avahi/issues/212 but we're already far away from the print subsystem.. I tried running avahi-browser under gdb but between the missing and not-autoloading debuginfo packages, and the callback-style structure, I wasn't able to catch it receiving the data that causes the problem. I guess my point here is that we have a complex, interdependent system, and when it fails, it is fairly opaque. At this point I am not sure what to do: is the root cause here the avahi bug? I am willing to spend the effort getting to the bottom of it but I can't figure out where to start. On 5/24/21 1:42 PM, Stephen John Smoogen wrote: I have had very bad luck in setting up new network printers over the last 4 years. I can get all of them to print from Windows and Mac, but every one of them from HP, Brother, and some other brands could not print anything from Linux. They were all 'Linux ready' but were doing it via either Google Print or a set of proprietary software blobs to be put on the computer. [They even came with ipp filters but they called the blobs]. I have a Brother MFC-27100W in my office which I print to via my wife's Mac because of this. I have written some basic info about how to find out whether your printer supports driverless [1] and how to setup it [2]. If you have at least F33 and have the device in your LAN, you can use temp queues for sure, otherwise you need to create a permanent queue via lpadmin: $ lpadmin -p -v -m everywhere -E If you still experience the issue, do feel free to file a bug for cups in bugzilla and I can look into it further. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Tue, 25 May 2021 at 04:04, Björn Persson wrote: > Kevin Kofler via devel wrote: > > Zdenek Dohnal wrote: > > > CUPS discovery is designed to run on secure, private LAN, so it is > > > expected that you have a protection against somebody connecting to your > > > WIFI. > > > > That is (still) a reasonable assumption for a home WiFi WLAN on which a > home > > printer is likely to be located. That is what WPA is for. > > > > Sure, you can connect a notebook or smartphone to untrusted public WiFi > > networks, but you normally do not print in such a network. > > None of that answers the question: How can I tell whether the printer > I'm sending to is on an untrusted network, on an imaginary network > created for a USB printer, or on a 1980s-style isolated LAN? Will the > name of the network interface be displayed when I choose a printer? > Will there at least be a visible difference between a permanently > configured printer and an auto-found printer, so I can continue to have > my printer configured and know that I'm sending to that one? > > Do I need to explain, detail by detail, the errors in the reasoning > "People don't print on untrusted networks. Therefore any network with a > printer on it is trusted.", or can people see the logical flaws on > their own? > > The truth is that most people know about it, and have decided that they can go 'meh' and keep living. The same as knowing that you have a high cumulative chance you will get killed by a car/bus to any other danger in your life.. but we put more work on making sure lightning doesn't hit us than driving safe. It comes down to the definition of 'untrusted' to most people. You (and me 20 years ago) are using the computer security definition while everyone else uses the 'if I didn't trust it I wouldn't print on it' gut level definition. Very very very few people really care about the logical flaws. If even the people who dictate policies that require secure printing did then there would have been a printing protocol written with the assumption that the network, printer and computers are hostile. Instead IPP, LPD and other print protocols have always been written with the assumption that the local network is some level of secure. You can force higher levels of security in some cases with a lot of work (if you choose the right printer, if you choose the right network configuration, if you set up additional authentications, etc) but you can also break out of those security levels in various ways because the underlying principles were not designed to this. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, 24 May 2021 at 22:30, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Solomon Peachy wrote: > > > On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote: > >> I do not see how that is the common use case. Why would I want to print > >> from my telephone? I do not even normally print from my notebook! > > > > I don't think it's controversial to say that one needs to print from > > whatever computing devices one uses. > > If I am sitting next to my printer, I have a desktop computer in front of > me > from which I can issue the print job, so why would I want to do it from a > notebook or smartphone? > > Kevin. No one is saying YOU want to print from your phone. However this software is not written just for you. Solomon and others do not write the software just for you but for the several million people who have to use printers in all different kinds of environments. For a good proportion of those people out there.. printing from the phone is an expected feature be it instagram memes or that pdf your department head sent out which is too small to read on the phone. So it is going to be something Solomon and others will focus on or they might as well scrap printing. -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 1:42 PM, Stephen John Smoogen wrote: > I have had very bad luck in setting up new network printers over the > last 4 years. I can get all of them to print from Windows and Mac, but > every one of them from HP, Brother, and some other brands could not > print anything from Linux. They were all 'Linux ready' but were doing > it via either Google Print or a set of proprietary software blobs to > be put on the computer. [They even came with ipp filters but they > called the blobs]. I have a Brother MFC-27100W in my office which I > print to via my wife's Mac because of this. > I have written some basic info about how to find out whether your printer supports driverless [1] and how to setup it [2]. If you have at least F33 and have the device in your LAN, you can use temp queues for sure, otherwise you need to create a permanent queue via lpadmin: $ lpadmin -p -v -m everywhere -E If you still experience the issue, do feel free to file a bug for cups in bugzilla and I can look into it further. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F [2] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Tue, May 25, 2021 at 10:03:13AM +0200, Björn Persson wrote: > None of that answers the question: How can I tell whether the printer > I'm sending to is on an untrusted network, on an imaginary network > created for a USB printer, or on a 1980s-style isolated LAN? Will the > name of the network interface be displayed when I choose a printer? > Will there at least be a visible difference between a permanently > configured printer and an auto-found printer, so I can continue to have > my printer configured and know that I'm sending to that one? If the printer is not on a local [1] network, then it won't appear automagically. Those that do appear show up as "queuename at host" or "mfg_model_hostname" (for native IPP printers, there's usually a partial MAC address in there by default too) Queues you create manually/permanently can be called whatever you want and point wherever you want. The standard GTK print dialog doesn't include any indication where a given printer identifier points, but others might. > Do I need to explain, detail by detail, the errors in the reasoning > "People don't print on untrusted networks. Therefore any network with a > printer on it is trusted.", or can people see the logical flaws on > their own? Trusted or not, "people need to print to something on their local network" is the overwhelmingly common use case. Meanwhile, CUPS's auto-discovery mechanisms have _always_ assumed the local network can be trusted. And if you don't trust the network, firewall off mDNS/browsed/whatever, and/or don't print to printers you don't recognize. Sure, someone could be spoofing a specific printer name/identifier just so they can capture a document *you* want to print, but if there's that level of persistant hostile presence on your local network, you're already completly screwed. [1] "local" means the local broadcast domain. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/25/21 10:22 AM, Tomasz Torcz wrote: > Dnia Mon, May 24, 2021 at 08:21:07PM -0400, Solomon Peachy napisał(a): >>> Well, if I want to configure the printer, I need to know what to point my >>> browser at. But sure, if a dialog gives me a link, that is a way. Though it >>> means yet another layer of indirection (bringing up the dialog first, only >>> to get redirected to a web interface). >> Running 'ippfind' will show you the list of all IPP-capable printers >> that are advertising themselves through mDNS, and the URI they can be >> reached at. > Nice command, but it returns host in the .local domain, resolving of which > doesn't work half of the time. The host sharing the printer has > normal, functioning FQDN, couldn't ippfind return it? IMHO the proper thing to do would be to investigate why you experience the issues with .local instead of rewritting software which uses .local addresses. Unless you have disabled weak dependencies in dnf, avahi and nss-mdns is installed together with CUPS, and .local resolution works fine with them. (The other issue is that 'driverless' binary sometimes fails to provide driverless ipp uri, which is a problem during searching for printers, but ippfind always finds the device just fine. I track it here [1]) I tried Avahi+resolved setup too and address resolving worked as well, but it needed more steps to make it work (enable mdns in resolved and enable mdns and llmr in NM for your network interface). If the resolution still doesn't work after checking your setup, it would be great if you filed a bug against nss-mdns or resolved, based on which solution do you use. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1954469 > I do control the network, including DNS server, but this zeroconf stuff > is a jungle. > > (some time ago I'v tried to share common LAN bookmarks using zeroconf, > but only Epiphany supported it. Firefox never get there - bz 173804. > Today, I don't even know what the equivalent of /etc/avahi/services/ is > in the systemd-resolved world). > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Dnia Mon, May 24, 2021 at 08:21:07PM -0400, Solomon Peachy napisał(a): > > > Well, if I want to configure the printer, I need to know what to point my > > browser at. But sure, if a dialog gives me a link, that is a way. Though it > > means yet another layer of indirection (bringing up the dialog first, only > > to get redirected to a web interface). > > Running 'ippfind' will show you the list of all IPP-capable printers > that are advertising themselves through mDNS, and the URI they can be > reached at. Nice command, but it returns host in the .local domain, resolving of which doesn't work half of the time. The host sharing the printer has normal, functioning FQDN, couldn't ippfind return it? I do control the network, including DNS server, but this zeroconf stuff is a jungle. (some time ago I'v tried to share common LAN bookmarks using zeroconf, but only Epiphany supported it. Firefox never get there - bz 173804. Today, I don't even know what the equivalent of /etc/avahi/services/ is in the systemd-resolved world). -- Tomasz TorczOnly gods can safely risk perfection, to...@pipebreaker.pl it's a dangerous thing for a man. — Alia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Kevin Kofler via devel wrote: > Zdenek Dohnal wrote: > > CUPS discovery is designed to run on secure, private LAN, so it is > > expected that you have a protection against somebody connecting to your > > WIFI. > > That is (still) a reasonable assumption for a home WiFi WLAN on which a home > printer is likely to be located. That is what WPA is for. > > Sure, you can connect a notebook or smartphone to untrusted public WiFi > networks, but you normally do not print in such a network. None of that answers the question: How can I tell whether the printer I'm sending to is on an untrusted network, on an imaginary network created for a USB printer, or on a 1980s-style isolated LAN? Will the name of the network interface be displayed when I choose a printer? Will there at least be a visible difference between a permanently configured printer and an auto-found printer, so I can continue to have my printer configured and know that I'm sending to that one? Do I need to explain, detail by detail, the errors in the reasoning "People don't print on untrusted networks. Therefore any network with a printer on it is trusted.", or can people see the logical flaws on their own? Björn Persson pgpQrJpctJGuj.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Tue, May 25, 2021 at 04:01:13AM +0200, Martin Kolman wrote: > > (And incidently, I do have a duplexing printer, a decade-plus-old > > Brother HL-5340D. Along with 31 others, though only 26 are plugged > > in > > at the moment. Isn't driver development/regression testing fun?) > Wow! :D In any case, just let me say thanks for all your work so far, > that's quite some determination! (Not to mention space, paper and power > budget. :) ) As a former colleague of mine put it, engineering is a highly productive behavioral disorder. (To be fair, 12 of those 32 were sent to me by other folks) Also, only four of those 32 printers are theoretically supported [1] by one of those newfangled printer application thingeys [2]. The rest depend on Gutenprint. ...Suffice it to say I have a vested interest in the legacy cups driver flow continuing to function until the as-of-yet-theoretical Gutenprint Printer Application is usable. [1] I haven't actually _tested_ them this way yet. [2] two by lprint, one by ipp-usb, and one by ps-printer-app. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote: >> I do not see how that is the common use case. Why would I want to print >> from my telephone? I do not even normally print from my notebook! > > I don't think it's controversial to say that one needs to print from > whatever computing devices one uses. If I am sitting next to my printer, I have a desktop computer in front of me from which I can issue the print job, so why would I want to do it from a notebook or smartphone? > X11 forwarding through SSH while running Wayland seems to work just fine > for me. *shrug* You're actually using a mix of X11 and Wayland then (with all the forwarded windows being X11/XWayland windows) though. >> More often than not, the "PDF-based print flow" just means that something >> client-side converts the PostScript to PDF before sending it to the shiny >> new "PDF-based print flow", only to have something in the driver filters >> convert the PDF back to PostScript before doing anything else. > > This hasn't been the case since Fedora 19 (Spring 2013), which, as part > of CUPS 1.6, switched to a PDF-native flow. Postscript is only used on > the edges, ie if the printer requires it or the application supplies it. But that is exactly my point: if the printer requires PostScript and the application supplies PostScript, but the queue expects PDF documents, this results in converting back and forth from PostScript to PDF and back to PostScript. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 08:52:13PM -0400, PGNet Dev wrote: > Endless theoretical discussions ... Interesting, but _is_ there > real-world, end-user doc available for installing and using papp-et-al > on Fedora, today? A "do this now" for end users? TBH, I'm unclear > (and no, I haven't gone digging ...) The short answer -- no, there isn't anything like thet yet. For PAPPL specifically, there won't ever be, because it is essentially a library/framework to be used by printer-specific stuff. > Admittedly, PS drivers are buggy-to-useless, and NONE of the "toner > level" reporting seems attached to reality in any way. For these old Postscript-capable HPs, there's the new 'ps-printer-app' (not yet packaged in Fedora) which will allow you to supply the PPD and everything should JustWork(tm). For native PCL, there's currently the 'hp-printer-app', but IIUC it's meant more as a demonstration of PAPPL than anything comprehensive. When Gutenprint is finally mashed together with PAPPL, it'll bring along comprehensive PCL4/5/5c support. There are probably plans afoot to do the same with hplip, which will also result in comprehensive PCL support. > If any of that^^ ceases to function, then that'll be a problem. Absolutely! I don't believe anyone is seriously advocating for retiring the status-quo "Legacy CUPS" driver model until (at minimum) the major printer driver families have been PAPPLized. > OTOH, If papp-future _at_the_very_least_ maintains that^^ > functionality through legacy wrappers, then I have zero concerns. I believe this exact scenario is planned as the final catch-all option. Just to be clear, when this Printer Application-only vision was first announced I was probably the most vocal skeptic in the room. Since then, the Openprinting folks have made consistent progress, addressing concerns, and filling in the missing pieces. They're working very, very hard to ensure printing continues to work... at least as well as it ever did, heh. (I've beeen around long enough to remember similar arguments being made about a new shiny upstart called CUPS over lpr[ng] and printcap. And look where we are today...) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, 2021-05-24 at 11:46 -0400, Solomon Peachy wrote: > On Mon, May 24, 2021 at 04:58:18PM +0200, Kevin Kofler via devel > wrote: > > Looks like you do not have a duplex printer. (Hint: Printing duplex > > is not > > always what you want. But never printing duplex makes even less > > sense. > > There's also short side duplex that makes sense in some cases for > > landscape > > printing.) > > Eh, duplexing is another basic document property, like paper size and > orientation. Granted, it's relatively likely to be overridden at > the time of printing... > > But by "settings" I was referring to things like ink density/droplet > size, weave patterns, dither modes, individual color channel curves, > and > other minutae that matter for specialized photo/art printing on > near-arbitrary media. This tunability is where Gutenprint shines, > even > in comparison to official manufacturer drivers on $ProprietaryOS. > > (And incidently, I do have a duplexing printer, a decade-plus-old > Brother HL-5340D. Along with 31 others, though only 26 are plugged > in > at the moment. Isn't driver development/regression testing fun?) Wow! :D In any case, just let me say thanks for all your work so far, that's quite some determination! (Not to mention space, paper and power budget. :) ) > > - Solomon > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Endless theoretical discussions ... Interesting, but _is_ there real-world, end-user doc available for installing and using papp-et-al on Fedora, today? A "do this now" for end users? TBH, I'm unclear (and no, I haven't gone digging ...) Here, I've got hundreds of networked printers. _Many_ of them old warhorses. E.g., ~ 50 HP LaserJet 4050n. Slow, but incredibly reliable. Unlike the modern 'options' from HP, made cheaply overseas, prone to breakage, and locked down with print-cartridge DRM, these 4050s have outlasted virtually every desktop & server we have, and quite a number of staff as well, and 3rd party parts & cartridges abound. CUPS 2.3.3op2 runs on virtually every Fedora desktop here, in addition to quite a few of the servers. For the 4050s, the drivers are all 'HP LaserJet 4050 Series pcl3, hpcups 3.19.6 (color, 2-sided printing)', and the connections are "socket://static.i.p.address". The PPDs are older than dirt, *PPD-Adobe: "4.3" * PPD file for HP LaserJet 4050 Series with CUPS. * Created by the CUPS PPD Compiler CUPS v1.5.0. *% (c) 2008 Copyright HP Development Company, LP *FormatVersion: "4.3" *FileVersion: "3.19.6" ... and work flawlessly. Admittedly, PS drivers are buggy-to-useless, and NONE of the "toner level" reporting seems attached to reality in any way. Neither, for me, has been a concern. Same holds generally true for all other networked printers, with the exception of some of high-volume/color machines that bundle their own raster/spool/networking/etc. If any of that^^ ceases to function, then that'll be a problem. Personally, I'm not the slightest bit interesting in wasting time/money replacing what work s well *AND* losing capbility for the sake of the next bringh-n-shiny OTOH, If papp-future _at_the_very_least_ maintains that^^ functionality through legacy wrappers, then I have zero concerns. Additional features/functionality are welcome gravy. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Tue, May 25, 2021 at 01:27:03AM +0200, Kevin Kofler via devel wrote: > All this is of no use if the printer does not actually implement that > though. Of course. That's where this whole "printer application" thingey comes in. > I do not see how that is the common use case. Why would I want to print from > my telephone? I do not even normally print from my notebook! I don't think it's controversial to say that one needs to print from whatever computing devices one uses. > Well, if I want to configure the printer, I need to know what to point my > browser at. But sure, if a dialog gives me a link, that is a way. Though it > means yet another layer of indirection (bringing up the dialog first, only > to get redirected to a web interface). Running 'ippfind' will show you the list of all IPP-capable printers that are advertising themselves through mDNS, and the URI they can be reached at. > My desktop and my notebook, i.e., the devices I actually SSH to at times > (from each other, usually), do have hardcoded IPs, yes. (And I also use X11 > forwarding when I SSH, so Wayland is a non-starter.) X11 forwarding through SSH while running Wayland seems to work just fine for me. *shrug* > More often than not, the "PDF-based print flow" just means that something > client-side converts the PostScript to PDF before sending it to the shiny > new "PDF-based print flow", only to have something in the driver filters > convert the PDF back to PostScript before doing anything else. This hasn't been the case since Fedora 19 (Spring 2013), which, as part of CUPS 1.6, switched to a PDF-native flow. Postscript is only used on the edges, ie if the printer requires it or the application supplies it. pdftopdf transforms proved to be a lot more robust than pstops due to PDF's semantics being far better defined. (Incidently, Fedora 19 is also when the switch to using mDNS for printer discovery happened..) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On Mon, May 24, 2021 at 10:41:07PM +0200, Kevin Kofler via devel wrote: >> I have never connected directly to a remote printer. > > It works quite well in Fedora these days. Well, the printers I had when I had a use for remote printing did not support it, sharing them through a computer was the only way. My current printer does support "wireless printing", but AFAIK there is no way to get it to connect to a secure WPA2-protected WLAN, it can only act as its own insecure hotspot. And I basically only ever print to it from one single computer (a non-moving desktop tower – yes, I still own such a thing), so I do not have a need to use it remotely to begin with. USB is the simplest solution. > Stop thinking about this in terms of AirPrint -- that's a very cut-down > proprietary variation of IPP. What we're talking about here is vastly > more capable. > > There's no reason why the printer can't represent its configuration > settings via IPP attributes. There's no reason why standard OS print > dialogs can't represent them to the user. All this is of no use if the printer does not actually implement that though. > You're correct, just not for the reasons you think. These days, > "User-friendly" means a printer-manufacturer-supplied standalone > printing app on their smartphone. I do not see how that is the common use case. Why would I want to print from my telephone? I do not even normally print from my notebook! That said, the smartphone hype has completely missed me so far. I still use a dumb cellphone. I recently got a PinePhone, and I'm only slowly getting used to it. (It does not even have a SIM card inserted yet because I have not picked a suitable contract for a smartphone yet.) Android and iOS are proprietary platforms that I just do not want. (I know AOSP is FOSS, but Android is more than just AOSP in practice.) >> So what is the port number then, or if it is dynamic, how do I find it >> out? > > Who cares what port (or even IP address) it's using? If the print > dialog knows the printer is there, it knows how to talk to it, including > its web interface. It's just another network printer, after all. Well, if I want to configure the printer, I need to know what to point my browser at. But sure, if a dialog gives me a link, that is a way. Though it means yet another layer of indirection (bringing up the dialog first, only to get redirected to a web interface). > (There's no inherent reason why wou wouldn't be able to assign fixed > ports, though that might get messy when more than one printer is > involved. Do you also hardcode IP addresses for every system on your > LAN?) My desktop and my notebook, i.e., the devices I actually SSH to at times (from each other, usually), do have hardcoded IPs, yes. (And I also use X11 forwarding when I SSH, so Wayland is a non-starter.) > We have a native PDF-based print flow, enabling far more consistent > rendering behavior than pure postscript, as well as a much richer set of > capabilities. More often than not, the "PDF-based print flow" just means that something client-side converts the PostScript to PDF before sending it to the shiny new "PDF-based print flow", only to have something in the driver filters convert the PDF back to PostScript before doing anything else. In the worst case, those conversions are done using ps2pdf and/or pdf2ps without any options, a process which ends up doing things such as lossy image recompression. (Those tools do not have roundtrip-safe defaults.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 10:41:07PM +0200, Kevin Kofler via devel wrote: > Except if the non-local printer was actually shared through another computer > on which it was attached, in which case you needed a printer driver either > on the computer sharing the printer (sharing it as a PostScript or PDF > printer) or on the computer actually doing the printing (if it was shared as > a raw queue), or even on both. All non-local printing I have ever done was > done like that. Sure, the system with the printer physically attached needs a "driver" of some sort. > I have never connected directly to a remote printer. It works quite well in Fedora these days. > And most of my printing has always been directly connected over parallel > port or USB. My current printer is connected over USB. I have a headless server with all of my printers attached (via USB). > Well, if the printer requires a printer application because it does not > support AirPrint, then how would the printer supply such a configuration > interface? The printer application will have to provide it! As opposed to "the printer driver has to provide it" or "the operating system has to provide it"? (Or "the individual application provides it" as is the case for Libreoffice, modern Firefox, and others?) Stop thinking about this in terms of AirPrint -- that's a very cut-down proprietary variation of IPP. What we're talking about here is vastly more capable. There's no reason why the printer can't represent its configuration settings via IPP attributes. There's no reason why standard OS print dialogs can't represent them to the user. Incidently, it's not just about the needs of containerization. IPP is vastly more expressive than PPDs, and is baked around the notion of bi-directional communication with the printer. Restricting selectable options based on loaded media or printer state? No problem! Reporting consumables? No problem! Performing maintainence tasks? No problem! (Note what while this is possible with CUPS, in practice very few CUPS drivers have actually implemented any of it, and I have yet to see a UI that properly reports/prevents illegal option combinations, a PPD feature that has been around since 1989) > And I have already explained why a web interface is not a user-friendly > configuration interface. You're correct, just not for the reasons you think. These days, "User-friendly" means a printer-manufacturer-supplied standalone printing app on their smartphone. > So what is the port number then, or if it is dynamic, how do I find it out? Who cares what port (or even IP address) it's using? If the print dialog knows the printer is there, it knows how to talk to it, including its web interface. It's just another network printer, after all. (There's no inherent reason why wou wouldn't be able to assign fixed ports, though that might get messy when more than one printer is involved. Do you also hardcode IP addresses for every system on your LAN?) > Dropping support for older hardware is always an unfriendly move. E.g., I am > also doing all I can to prevent requirements on newer SSE (or even AVX) > versions from creeping in. Unfriendly, sure. But indefinitely maintaining support for old stuff isn't viable either, and it's also "unfriendly" to have new features remain inaccessable because older devices don't support it. Note I say this as someone who maintains drivers for a couple of specialist printers for which new media has been unobtanium for at least five years, and whose power supplies have a tendency to spotaneously explode. > > Meanwhile. The ultimate goal has not yet been realized, but with each > > incremental milestone along the way, it's getting closer. Ironically, > > the existing Legacy CUPS + cups-filters + drivers printing flow has been > > the largest beneficiary of these improvements; I wouldn't consider that > > a failure. > > How has it benefitted? All I see is it getting labeled deprecated and > constantly threatened of removal. Modern (>2010) networked printers JustWork(tm), without need for local drivers. CUPS-shared printers JustWork(tm), also without local drivers. Folks with smartphones can print to most CUPS-attached printers, again, no drivers. We have a standard _lossless_ raster image format that all printers must accept. We have a native PDF-based print flow, enabling far more consistent rendering behavior than pure postscript, as well as a much richer set of capabilities. We have end-to-end colorspace awareness, with automatic colorspace conversion if the appropriate profiles are installed. We have sane auto-scaling/cropping modes that generally do the right thing in the face of aspect ratio mismatches. We're closer than ever to a universal printing system that is not tied to any specific OS or client, and that behaves identically no matter where or how the printer is attached. Underpinning all of this are formally
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > The legacy CUPS *direct-attached* model simply doesn't work with > containerized/sandboxed applications that are all the vogue these days. So this is yet another functionality regression coming from that containerization nonsense! Why do we all have to pay the price for containerization even if we do not use it? > But if your printer was already non-local vs the system doing the > printing (ie on "the network" somewhere) then this whole conversation is > moot, because you haven't had to install a native driver locally for > many years. Except if the non-local printer was actually shared through another computer on which it was attached, in which case you needed a printer driver either on the computer sharing the printer (sharing it as a PostScript or PDF printer) or on the computer actually doing the printing (if it was shared as a raw queue), or even on both. All non-local printing I have ever done was done like that. I have never connected directly to a remote printer. And most of my printing has always been directly connected over parallel port or USB. My current printer is connected over USB. >> > Except for Gutenprint, I'm not aware of any printer driver provider >> > which plans to provide more specific options with a printer >> > application. >> >> Which implies that, from a user perspective, there will be a noticeable >> loss of functionality. > > How so? I mean, whether you supply the printing options from the lp > command line, the printer's web UI (this includes CUPS' webserver) or > the system printing dialog the functionality will still be there. Well, if the printer requires a printer application because it does not support AirPrint, then how would the printer supply such a configuration interface? The printer application will have to provide it! And I have already explained why a web interface is not a user-friendly configuration interface. >> A web interface requires bringing up a web browser, manually pointing it >> to http://localhost: where is a port number that has to be >> manually looked up from some manual, > > No, it's a standard property, and I'd presume a "generic IPP print > dialog" would have a big fat button that, when mashed, takes you to the > appropriate configuration interface. So what is the port number then, or if it is dynamic, how do I find it out? > Honestly? The simplest approach is to copy what every other platform out > there already does, and simply drop support for sufficiently old > hardware. Fedora routinely does this, why should printers be any > different? Dropping support for older hardware is always an unfriendly move. E.g., I am also doing all I can to prevent requirements on newer SSE (or even AVX) versions from creeping in. > Meanwhile. The ultimate goal has not yet been realized, but with each > incremental milestone along the way, it's getting closer. Ironically, > the existing Legacy CUPS + cups-filters + drivers printing flow has been > the largest beneficiary of these improvements; I wouldn't consider that > a failure. How has it benefitted? All I see is it getting labeled deprecated and constantly threatened of removal. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Zdenek Dohnal wrote: > CUPS discovery is designed to run on secure, private LAN, so it is > expected that you have a protection against somebody connecting to your > WIFI. That is (still) a reasonable assumption for a home WiFi WLAN on which a home printer is likely to be located. That is what WPA is for. Sure, you can connect a notebook or smartphone to untrusted public WiFi networks, but you normally do not print in such a network. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Chris Murphy wrote: > Consumer printers have trended toward having an RGB only interface, > making it impossible to directly control them per channel. In effect, > the print driver is becoming part of the printer's firmware. My Canon PIXMA MG3650 is definitely a consumer printer (and a recent one), and it supports CMY-only printing via the Gutenprint driver. It speaks a proprietary protocol, offloading most of the work to the driver, as is common for cheap printers. Why would the printer do the RGB to CMYK (or CMY) conversion when the computer can do it? (That said, it appears to support AirPrint, at least the USB endpoint for it is advertised. But I have no idea how flexible the AirPrint mode is, if it works at all. But definitely not as much as Gutenprint, I am pretty sure.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > But by "settings" I was referring to things like ink density/droplet > size, weave patterns, dither modes, individual color channel curves, and > other minutae that matter for specialized photo/art printing on > near-arbitrary media. This tunability is where Gutenprint shines, even > in comparison to official manufacturer drivers on $ProprietaryOS. Well, choosing whether you want a printout with less ink consumption or one that looks more "perfect" is an important choice, and it's only found in the advanced, driver-specific settings. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, 24 May 2021 at 12:29, Solomon Peachy wrote: > On Mon, May 24, 2021 at 05:14:41PM +0200, Kevin Kofler via devel wrote: > > The real issue here is the "once CUPS removes printer driver support" > > premise that makes a "transition technology" necessary in the first > place. > > The change removes functionality that has been just working for decades. > > The legacy CUPS *direct-attached* model simply doesn't work with > containerized/sandboxed applications that are all the vogue these days. > > But if your printer was already non-local vs the system doing the > printing (ie on "the network" somewhere) then this whole conversation is > moot, because you haven't had to install a native driver locally for > many years. > > > > Except for Gutenprint, I'm not aware of any printer driver provider > > > which plans to provide more specific options with a printer > application. > > > > Which implies that, from a user perspective, there will be a noticeable > loss > > of functionality. > > How so? I mean, whether you supply the printing options from the lp > command line, the printer's web UI (this includes CUPS' webserver) or > the system printing dialog the functionality will still be there. > > > > They seem to be okay with AirPrint. > > > > So, how, if at all, can you configure an AirPrint printer? > > The same way you configure any other printer; ie via its designated > configuration interface. This can be the printer control panel, an > embedded web server, or arbitrary print-time options; whatever the > printer and application/platform supports. > > > A web interface is not a complete replacement for "what CUPS provides > right > > now", which is a driver-independent key-value property interface that is > > used both by desktop environments and/or distributions to provide > > configuration interfaces in their native toolkit (e.g., > > system-config-printer, kde-print-manager, etc.) and by applications to > allow > > changing printer settings for individual printouts from within the > > application. > > IPP already supports arbitrary key-value properties. That isn't the > problem; instead it's getting generic driver/device-independent > configuration tools/interfaces to present them properly. > > These interfaces represent their own level of hell, and they are _all_ > broken in some way or another, even with the mature PPD-based CUPS flow. > > (And I say that as a Gutenprint developer who has to deal with the > support headaches..) > > > A web interface requires bringing up a web browser, manually pointing it > to > > http://localhost: where is a port number that has to be > manually > > looked up from some manual, > > No, it's a standard property, and I'd presume a "generic IPP print > dialog" would have a big fat button that, when mashed, takes you to the > appropriate configuration interface. > > > And yet, that design is just not (and still not) a fully functional > > replacement for the functionality you are trying to remove and has > achieved > > little to no adoption. That is the point where it is simply time to > admit > > failure. > > Honestly? The simplest approach is to copy what every other platform out > there already does, and simply drop support for sufficiently old > hardware. Fedora routinely does this, why should printers be any > different? > > Mainly because printers tend to either live incredibly short lives or horribly long ones (like my old neighbours HP Laserjet 4 which they got from their Dad. The printer is at least 4 years older than the student.) I would say it was a lone example, but I have seen 4 students in the last year with some older printer because the new one didn't work with Windows or their Mac but their parents' 10+ year old one was running fine so they got it. Going from the various University email lists, these older things end up being the ones which departments keep going for decades also. Printers tend to be seen as major cost products for a lot of businesses and university/government departments mainly from when they were. Mainly because too many departments bought cheap ones in the past which ended up costing too much in service calls (which is what the printing company wanted.. razor blade model). Instead you end up having to fill out giant amounts of paperwork to justify a 50 dollar off the shelf printer but you can get a 40,000 dollar one approved quicker. You then end up keeping that 40,000 one going for as long as you can.. because it may be 20 years before you get another one. [The printer company pretty much makes as much money with either purchase.. it is either on the front end or the back end.] > Meanwhile. The ultimate goal has not yet been realized, but with each > incremental milestone along the way, it's getting closer. Ironically, > the existing Legacy CUPS + cups-filters + drivers printing flow has been > the largest beneficiary of these improvements; I wouldn't consider that > a failure. > > - Solomon > -- > Solomon
Re: When is pappl going to be good enough to replace cups?
Zdenek Dohnal wrote: > CUPS discovery is designed to run on secure, private LAN, so it is > expected that you have a protection against somebody connecting to your > WIFI. That was a reasonable assumption in the 1980s. It's 2021 now, and every program that communicates must cope with a hostile environment. Here in the third millennium we have laptops moving between networks. There are public hotspots and mobile Internet, plenty of connections that aren't private LANs. Home routers are typically crap and never get any security updates, and the Insecurity of Things ensures that there are easily cracked devices in every home and office. As for wifi, it has a long history of flawed security protocols. A recent study found three protocol design flaws in the standards, including the latest WPA3 specification, and nine implementation defects that can be used to attack devices that trust the wifi network to protect them. Assuming that all the nodes on the local link are friendly is criminally naïve. Björn Persson pgpLHHjA7RfBz.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 05:14:41PM +0200, Kevin Kofler via devel wrote: > The real issue here is the "once CUPS removes printer driver support" > premise that makes a "transition technology" necessary in the first place. > The change removes functionality that has been just working for decades. The legacy CUPS *direct-attached* model simply doesn't work with containerized/sandboxed applications that are all the vogue these days. But if your printer was already non-local vs the system doing the printing (ie on "the network" somewhere) then this whole conversation is moot, because you haven't had to install a native driver locally for many years. > > Except for Gutenprint, I'm not aware of any printer driver provider > > which plans to provide more specific options with a printer application. > > Which implies that, from a user perspective, there will be a noticeable loss > of functionality. How so? I mean, whether you supply the printing options from the lp command line, the printer's web UI (this includes CUPS' webserver) or the system printing dialog the functionality will still be there. > > They seem to be okay with AirPrint. > > So, how, if at all, can you configure an AirPrint printer? The same way you configure any other printer; ie via its designated configuration interface. This can be the printer control panel, an embedded web server, or arbitrary print-time options; whatever the printer and application/platform supports. > A web interface is not a complete replacement for "what CUPS provides right > now", which is a driver-independent key-value property interface that is > used both by desktop environments and/or distributions to provide > configuration interfaces in their native toolkit (e.g., > system-config-printer, kde-print-manager, etc.) and by applications to allow > changing printer settings for individual printouts from within the > application. IPP already supports arbitrary key-value properties. That isn't the problem; instead it's getting generic driver/device-independent configuration tools/interfaces to present them properly. These interfaces represent their own level of hell, and they are _all_ broken in some way or another, even with the mature PPD-based CUPS flow. (And I say that as a Gutenprint developer who has to deal with the support headaches..) > A web interface requires bringing up a web browser, manually pointing it to > http://localhost: where is a port number that has to be manually > looked up from some manual, No, it's a standard property, and I'd presume a "generic IPP print dialog" would have a big fat button that, when mashed, takes you to the appropriate configuration interface. > And yet, that design is just not (and still not) a fully functional > replacement for the functionality you are trying to remove and has achieved > little to no adoption. That is the point where it is simply time to admit > failure. Honestly? The simplest approach is to copy what every other platform out there already does, and simply drop support for sufficiently old hardware. Fedora routinely does this, why should printers be any different? Meanwhile. The ultimate goal has not yet been realized, but with each incremental milestone along the way, it's getting closer. Ironically, the existing Legacy CUPS + cups-filters + drivers printing flow has been the largest beneficiary of these improvements; I wouldn't consider that a failure. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 04:58:18PM +0200, Kevin Kofler via devel wrote: > Looks like you do not have a duplex printer. (Hint: Printing duplex is not > always what you want. But never printing duplex makes even less sense. > There's also short side duplex that makes sense in some cases for landscape > printing.) Eh, duplexing is another basic document property, like paper size and orientation. Granted, it's relatively likely to be overridden at the time of printing... But by "settings" I was referring to things like ink density/droplet size, weave patterns, dither modes, individual color channel curves, and other minutae that matter for specialized photo/art printing on near-arbitrary media. This tunability is where Gutenprint shines, even in comparison to official manufacturer drivers on $ProprietaryOS. (And incidently, I do have a duplexing printer, a decade-plus-old Brother HL-5340D. Along with 31 others, though only 26 are plugged in at the moment. Isn't driver development/regression testing fun?) - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 9:26 AM Kevin Kofler via devel wrote: > > Kevin Kofler via devel wrote: > > Solomon Peachy wrote: > >> On the other hand, the average person wanting to "just print something" > >> can do just that without ever adjusting any settings. > > > > Looks like you do not have a duplex printer. (Hint: Printing duplex is not > > always what you want. But never printing duplex makes even less sense. > > There's also short side duplex that makes sense in some cases for > > landscape printing.) > > Another example: What do you do when you run out of black ink at a time > where no stores are open (night, weekend, hard lockdown, etc.)? With > Gutenprint, it is very easy to change from CMYK mode to CMY mode with > composite black. Consumer printers have trended toward having an RGB only interface, making it impossible to directly control them per channel. In effect, the print driver is becoming part of the printer's firmware. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Kevin Kofler via devel wrote: > Solomon Peachy wrote: >> On the other hand, the average person wanting to "just print something" >> can do just that without ever adjusting any settings. > > Looks like you do not have a duplex printer. (Hint: Printing duplex is not > always what you want. But never printing duplex makes even less sense. > There's also short side duplex that makes sense in some cases for > landscape printing.) Another example: What do you do when you run out of black ink at a time where no stores are open (night, weekend, hard lockdown, etc.)? With Gutenprint, it is very easy to change from CMYK mode to CMY mode with composite black. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Zdenek Dohnal wrote: > Printer applications started as a transition technology - a way how to > support older printers once CUPS removes printer driver support - so for > now they are here for backward compatibility. The real issue here is the "once CUPS removes printer driver support" premise that makes a "transition technology" necessary in the first place. The change removes functionality that has been just working for decades. > Except for Gutenprint, I'm not aware of any printer driver provider > which plans to provide more specific options with a printer application. Which implies that, from a user perspective, there will be a noticeable loss of functionality. > They seem to be okay with AirPrint. So, how, if at all, can you configure an AirPrint printer? > AFAIK PAPPL (and even the old lprint which I packaged into Fedora last > year, but his web interface is going to substituted by PAPPL web ui in > the next release) provides a default web interface which you can use for > configuring printer options. >> >> From the end user perspective, the new approach brings only >> disadvantages. > Since PAPPL provides web ui and CLI, which you can use for configuring > your device, IMHO it is not much different from what CUPS provides right > now. A web interface is not a complete replacement for "what CUPS provides right now", which is a driver-independent key-value property interface that is used both by desktop environments and/or distributions to provide configuration interfaces in their native toolkit (e.g., system-config-printer, kde-print-manager, etc.) and by applications to allow changing printer settings for individual printouts from within the application. A web interface requires bringing up a web browser, manually pointing it to http://localhost: where is a port number that has to be manually looked up from some manual, and then using a web form (rather than a native dialog) to change any settings. And changing the settings for just one printout requires bringing up the web interface as previously described, then making the printout through the application, and then going back to the web interface to change the settings back, meaning you now have to deal with two applications (the browser and the actual application) instead of one. I never use http://localhost:631 to configure CUPS, it is just not practical (even though I happen to know the port number by heart, which is also not the case for the new PAPPL port). > CUPS developers (PWG+Openprinting) decided to remove deprecated > functionality (which has big issues regarding security and distribution) > in the future in favor of standardized, less hardware dependent > solution, which is supported by 98% of printers released since 2010. The > functionality has been deprecated for 11 years and still be only > deprecated (not removed) until there is a coverage for older devices by > printer applications and have some tools for installing older printers > via printer applications. If you try and fail to remove something for 11 years, that should be clear evidence that that something is actually needed and simply cannot be removed. > CUPS developers came up with printer application design for older device > users, so they don't have to buy a new device, created first three > printer applications - ippeveprinter (shipped in CUPS itself, under > cups-printerapp subpackage in Fedora), lprint (support for label > printers) and ps-printer-app (which covers postscript printers) -, plans > to implement printer applications for other widely packaged printer > drivers and publicly provides a documentation how to create printer > applications for corner use cases. And yet, that design is just not (and still not) a fully functional replacement for the functionality you are trying to remove and has achieved little to no adoption. That is the point where it is simply time to admit failure. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Solomon Peachy wrote: > On the other hand, the average person wanting to "just print something" > can do just that without ever adjusting any settings. Looks like you do not have a duplex printer. (Hint: Printing duplex is not always what you want. But never printing duplex makes even less sense. There's also short side duplex that makes sense in some cases for landscape printing.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 3:29 AM, Zdenek Dohnal wrote: Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. This application will advertise the device on localhost via MDNS protocol and will communicate with CUPS via IPP, both public well-known protocols. The only place where the data can turn into proprietary is filtering, but it's the same with printer drivers. -- Greetings, Is there any plan to support these IPP printer applications over Unix domain sockets? I manage a virtual printer that uses CUPS filters and backends to capture documents to an application database. We have been using CUPS authentication features to control who can use the printer, and not to have to reimplement authentication on the filter and backends. With network bound IPP applications, anyone on the same multiuser machine would be able to bypass CUPS and send documents directly unless I duplicate CUPS authentication functionality. Unix sockets would help with that, ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 01:48:08PM +0200, Vitaly Zaitsev via devel wrote: > Breaking what has worked well for years is the worst idea, IMO. It worked well for years in the same sense that sysvinit worked well; with a great deal of bailing wire, angst, and the occasional blood sacrifice to the elder gods. > Introducing a new API -> implementing new apps for all available printers -> > deprecating the old API -> removing the old API. > > ^ this strategy should be used. Fortunately, it is! - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 12:33:45PM +0200, Vitaly Zaitsev via devel wrote: > On 24.05.2021 12:30, Solomon Peachy wrote: > > Not only is it possible, it's been done. > > For all existing printers in the world? I don't believe. For all printers? Of course not. But that wasn't what Zdenek wrote. At least two printer families have working Printer Applications _today_. There is a reasonable plan in place to port several more, and once complete that will encompass the vast majority of the printers still in use. Meanwhile, stuff that never had a native Linux/CUPS driver still won't work. And stuff that was only ever made available with a proprietary binary driver can be wrapped with legacy CUPS, which itself is a "printer application". Printing has always been an awful, awful mess, and the fact it works as well as it does is a testatment to the thankless efforts of the OpenPrinting folks (and their predecessors). Indeed, these days, it's a rare (new-ish) printer that doesn't JusWork(tm). The Printer Application model is attempting to bring the older/niche models into the same "driverless" paradigm. This is a VeryGoodThing(tm), as it means printing will automagically JustWork(tm) for just about everyone -- Linux, Android, iOS, MacOS, and even Windows! We're even going to (finally!) be getting sane color profile management out of the box! - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 13:23, Zdenek Dohnal wrote: I would have a counter question - do you think that all existing printers in the world which have a printer driver work correctly on Linux? I don't believe.:) Breaking what has worked well for years is the worst idea, IMO. OpenPrinting community plans to create printer applications for widely known printer drivers, plus those applications can use your own PPD file once you upload it to the application and the same is planned to do with plugins/firmware (you will be able to use 3rd party plugins and firmware with printer applications). Good, but only when this task is fully completed, the deprecated CUPS features can be removed. Introducing a new API -> implementing new apps for all available printers -> deprecating the old API -> removing the old API. ^ this strategy should be used. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, 24 May 2021 at 03:30, Zdenek Dohnal wrote: > Hi Stephen, > On 5/22/21 1:37 AM, Stephen John Smoogen wrote: > > > > Yes it is a bad situation but I don’t think there are a set of ‘CUPS’ > developers versus one person trying to keep the software going. Apple > stopped supporting the product and msweet is working for himself now. > lprint seems to be a ‘make a best out of a bad situation’. > > CUPS is supported and developed by Openprinting+PWG community, which > contains Mike Sweet and distro maintainers (like me). > My apologies. > > I don’t know what any other alternatives there are as more and more > printers seem to be wanting you to send your prints to some central web > server they own and then will talk with your printer and print the task. Or > they say they support the IPP but really its an app on your machine which > just takes it and makes it something proprietary and trying to talk ipp to > the printer fails. > > You don't need any central web server or special app to be able to print > via the current printer standards, which are driverless (IPP > Everywhere/Airprint/Google Cloud Print). In case your device is on your LAN > or USB, you don't even install the device permanently - CUPS is able to > pick up Avahi messages about a device being in LAN or on localhost (in case > of USB printers after you install ipp-usb) and set up a temp queue for you > when you are about to print - the queue is removed after successful > printing. > I have had very bad luck in setting up new network printers over the last 4 years. I can get all of them to print from Windows and Mac, but every one of them from HP, Brother, and some other brands could not print anything from Linux. They were all 'Linux ready' but were doing it via either Google Print or a set of proprietary software blobs to be put on the computer. [They even came with ipp filters but they called the blobs]. I have a Brother MFC-27100W in my office which I print to via my wife's Mac because of this. > Printers outside of your LAN need to be installed permanently right now > via printer configuration tools (CUPS web ui, gnome-control-center, > lpadmin) or via cups-browsed. We plan to support such devices by printer > profiles, so the queues won't installed permanently either. > > Devices which currently depend on a deprecated functionality - printer > drivers and raw queues - will need a printer application once the > deprecated functionality is removed from CUPS. This application will > advertise the device on localhost via MDNS protocol and will communicate > with CUPS via IPP, both public well-known protocols. The only place where > the data can turn into proprietary is filtering, but it's the same with > printer drivers. > > -- > Zdenek Dohnal > Software Engineer > Red Hat Czech - Brno TPB-C > > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 08:51:11AM +0200, Zdenek Dohnal wrote: > Except for Gutenprint, I'm not aware of any printer driver provider > which plans to provide more specific options with a printer application. > They seem to be okay with AirPrint. So printer application will be > needed only for older (<2010) printer models in most cases. Yeah, Gutenprint is a special case. Or perhaps it's more accurate to say it represents several special cases, because its intended use cases require the ability to carefully tune the output. On the other hand, the average person wanting to "just print something" can do just that without ever adjusting any settings. Disclaimer; I wrote most of the dye-sublimation code in Gutenprint. That family of printers is one of the "verticals" that has completely ignored IPP, due in part to product lifecycles that routinely exceed a decade. Instead, dyesub makers have opted to sell little appliances to provide network connectivity, including SMB for "hot folder" support. Of the devices I'm aware of, all but one is running Linux + CUPS + Gutenprint. (The exception still running CUPS, only with their own driver) Anyway. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:33 PM, Vitaly Zaitsev via devel wrote: > On 24.05.2021 12:30, Solomon Peachy wrote: >> Not only is it possible, it's been done. > > For all existing printers in the world? I don't believe. I would have a counter question - do you think that all existing printers in the world which have a printer driver work correctly on Linux? I don't believe. :) OpenPrinting community plans to create printer applications for widely known printer drivers, plus those applications can use your own PPD file once you upload it to the application and the same is planned to do with plugins/firmware (you will be able to use 3rd party plugins and firmware with printer applications). -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:30 PM, Solomon Peachy wrote: > On Mon, May 24, 2021 at 10:18:17AM +0200, Vitaly Zaitsev via devel wrote: >> On 24.05.2021 08:51, Zdenek Dohnal wrote: >>> OpenPrinting plans >>> to implement printer applications for widely known printer driver >>> packages during GSoC [1] and provides a documentation for driver >>> developers who wants to implement their printer application faster[2][3]. >> I don't think this is even possible in theory. > Not only is it possible, it's been done. > > - Solomon Thanks, Solomon :) > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/24/21 12:37 PM, Vitaly Zaitsev via devel wrote: > On 24.05.2021 10:33, Zdenek Dohnal wrote: >> The future removal isn't due lacking manpower, but due moving to >> standardized and less hardware dependent solutions - driverless >> standards such as IPP Everywhere. And those standards are supported >> by 98% devices released after 2010. > > HP LaserJet P1102w and many others (also called as "win-printers"). It > will be discovered through IPP Everywhere / Avahi, but will not print > anything until the proprietary "plugin" is installed. > I answered you in your original thread, no point of spamming the same message under every related email in the conversation tree. I told you there is a plan for printer application for foo2zjs and you can join the community to implement it, you disagreed, I beg to differ. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 10:33, Zdenek Dohnal wrote: The future removal isn't due lacking manpower, but due moving to standardized and less hardware dependent solutions - driverless standards such as IPP Everywhere. And those standards are supported by 98% devices released after 2010. HP LaserJet P1102w and many others (also called as "win-printers"). It will be discovered through IPP Everywhere / Avahi, but will not print anything until the proprietary "plugin" is installed. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 12:30, Solomon Peachy wrote: Not only is it possible, it's been done. For all existing printers in the world? I don't believe. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Mon, May 24, 2021 at 10:18:17AM +0200, Vitaly Zaitsev via devel wrote: > On 24.05.2021 08:51, Zdenek Dohnal wrote: > > OpenPrinting plans > > to implement printer applications for widely known printer driver > > packages during GSoC [1] and provides a documentation for driver > > developers who wants to implement their printer application faster[2][3]. > > I don't think this is even possible in theory. Not only is it possible, it's been done. - Solomon -- Solomon Peachypizza at shaftnet dot org (email) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode) signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/22/21 9:58 PM, Björn Persson wrote: > > So what I'm hearing is that Fedora will soon stop working with my > printer, There isn't a specific date for removing the functionality, now we work on implementing printer applications for widely known and open sourced printer drivers. > because if there isn't enough manpower to even keep existing > printer drivers in place, The future removal isn't due lacking manpower, but due moving to standardized and less hardware dependent solutions - driverless standards such as IPP Everywhere. And those standards are supported by 98% devices released after 2010. > then who is going to write a bunch of pappls > for not-quite-brand-new printers? Openprinting community plans to write printer applications for some widely known printer drivers during Google Summer of Code in the future[1]. For others - we expect other communities which want those devices to work once drivers are removed from CUPS will step up and implement the missing parts. Openprinting created a printer application library [2] and documentation for them [3][4]. > > And if the bright and shiny future is that USB printers look just like > network printers, and network printers just show up without any > installation, then I'm starting to wonder how I will know whether I'm > sending my sensitive document to my USB printer or to some impostor on > a wifi network. CUPS discovery is designed to run on secure, private LAN, so it is expected that you have a protection against somebody connecting to your WIFI. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects#converting_classic_cups_printer_drivers_into_printer_applications_multiple_students [2] https://github.com/michaelrsweet/pappl/ [3] https://openprinting.github.io/documentation/01-printer-application/ [4] https://openprinting.github.io/documentation/02-designing-printer-drivers/ > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 08:51, Zdenek Dohnal wrote: OpenPrinting plans to implement printer applications for widely known printer driver packages during GSoC [1] and provides a documentation for driver developers who wants to implement their printer application faster[2][3]. I don't think this is even possible in theory. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 24.05.2021 09:29, Zdenek Dohnal wrote: You don't need any central web server or special app to be able to print via the current printer standards, which are driverless (IPP Everywhere/Airprint/Google Cloud Print). HP JaserJet P1102(w) and many other HP printers will not print without installing a proprietary "plugin" (or a special OSS converter foo2zjs) for both Wi-Fi and USB. Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. I think that the current version of CUPS should not be replaced by a new one with features removed. Move it, for example, to the cups-legacy package. Nobody is going to write application-based drivers for all existing legacy hardware. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Hi Stephen, On 5/22/21 1:37 AM, Stephen John Smoogen wrote: > > > Yes it is a bad situation but I don’t think there are a set of ‘CUPS’ > developers versus one person trying to keep the software going. Apple > stopped supporting the product and msweet is working for himself now. > lprint seems to be a ‘make a best out of a bad situation’. CUPS is supported and developed by Openprinting+PWG community, which contains Mike Sweet and distro maintainers (like me). > > I don’t know what any other alternatives there are as more and more > printers seem to be wanting you to send your prints to some central > web server they own and then will talk with your printer and print the > task. Or they say they support the IPP but really its an app on your > machine which just takes it and makes it something proprietary and > trying to talk ipp to the printer fails. You don't need any central web server or special app to be able to print via the current printer standards, which are driverless (IPP Everywhere/Airprint/Google Cloud Print). In case your device is on your LAN or USB, you don't even install the device permanently - CUPS is able to pick up Avahi messages about a device being in LAN or on localhost (in case of USB printers after you install ipp-usb) and set up a temp queue for you when you are about to print - the queue is removed after successful printing. Printers outside of your LAN need to be installed permanently right now via printer configuration tools (CUPS web ui, gnome-control-center, lpadmin) or via cups-browsed. We plan to support such devices by printer profiles, so the queues won't installed permanently either. Devices which currently depend on a deprecated functionality - printer drivers and raw queues - will need a printer application once the deprecated functionality is removed from CUPS. This application will advertise the device on localhost via MDNS protocol and will communicate with CUPS via IPP, both public well-known protocols. The only place where the data can turn into proprietary is filtering, but it's the same with printer drivers. -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/22/21 12:17 AM, Kevin Kofler via devel wrote: > Zdenek Dohnal wrote: >> It is a library for printer applications [1], not a substitute for CUPS. >> CUPS is still present and is going to be. >> >> There will be more printer applications coming into Fedora >> (ps-printer-app f.e.) and one already is (lprint). >> >> >> The purpose of the library is have a way how to implement a support for >> devices which don't support IPP Everywhere [2] or its derivations >> (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can >> be seen by CUPS once we remove printer driver support. Hi Kevin, > I really don't see how the switch from drivers to printer applications is an > improvement. Printer applications started as a transition technology - a way how to support older printers once CUPS removes printer driver support - so for now they are here for backward compatibility. Except for Gutenprint, I'm not aware of any printer driver provider which plans to provide more specific options with a printer application. They seem to be okay with AirPrint. So printer application will be needed only for older (<2010) printer models in most cases. > All the existing drivers have to be ported to the new interface > to essentially emulate the IPP protocol. And now, instead of being able to > configure printer options through the existing graphical CUPS frontends (or > just set them temporarily in the individual application, which most > applications support nowadays), you end up with a CLI as in the old lpr > days, e.g.: > https://www.msweet.org/lprint/lprint.html#printing-options > https://www.msweet.org/lprint/lprint.html#setting-default-options > or at best, a GUI provided by the printer application in some arbitrary > toolkit, which will likely be GTK for Gutenprint (forcing KDE Plasma users > to use a GTK application to configure their printer) and Qt for HPLIP > (forcing GNOME users to use a Qt application to configure their printer). > Instead of a standardized interface to configure printer options, every > printer application now has to reinvent its own one. AFAIK PAPPL (and even the old lprint which I packaged into Fedora last year, but his web interface is going to substituted by PAPPL web ui in the next release) provides a default web interface which you can use for configuring printer options. > > From the end user perspective, the new approach brings only disadvantages. Since PAPPL provides web ui and CLI, which you can use for configuring your device, IMHO it is not much different from what CUPS provides right now. > From the driver developer perspective, it means a lot of porting work. It depends on which devices he creates drivers for - if the device supports Airprint, he can choose to let Airprint to support the printer and no printer application is needed. >From my daily work, I see people often use drivers because they are used to using it and don't know they don't need to use it. For older devices, yes, there needs to be a printer application to be able to use the device with CUPS in the future, but OpenPrinting plans to implement printer applications for widely known printer driver packages during GSoC [1] and provides a documentation for driver developers who wants to implement their printer application faster[2][3]. > The > only ones who will benefit are the CUPS developers, who will have > successfully outsourced their work to other projects that now have to do > their work for them. CUPS developers (PWG+Openprinting) decided to remove deprecated functionality (which has big issues regarding security and distribution) in the future in favor of standardized, less hardware dependent solution, which is supported by 98% of printers released since 2010. The functionality has been deprecated for 11 years and still be only deprecated (not removed) until there is a coverage for older devices by printer applications and have some tools for installing older printers via printer applications. CUPS developers came up with printer application design for older device users, so they don't have to buy a new device, created first three printer applications - ippeveprinter (shipped in CUPS itself, under cups-printerapp subpackage in Fedora), lprint (support for label printers) and ps-printer-app (which covers postscript printers) -, plans to implement printer applications for other widely packaged printer drivers and publicly provides a documentation how to create printer applications for corner use cases. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects [2] https://openprinting.github.io/documentation/01-printer-application/ [3] https://openprinting.github.io/documentation/02-designing-printer-drivers/ > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: >
Re: When is pappl going to be good enough to replace cups?
Hi Vitaly, Openprinting community (which I am a part of the community) plans to have printer applications for printer drivers shipped in Ubuntu implemented during Google Summer of Code [1] by multiple students. foo2zjs is in Ubuntu too, so there's a plan to implement a printer application for it. However, if you don't want to rely/wait for GSoC results, one student from Google Season of Docs last year created a documentation for implementing printer applications [2][3], so you can learn more about how a printer application works and you're welcome to join our OpenPrinting community and help us implementing the foo2zjs printer application. [1] https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects [2] https://openprinting.github.io/documentation/01-printer-application/ [3] https://openprinting.github.io/documentation/02-designing-printer-drivers/ On 5/21/21 10:30 AM, Vitaly Zaitsev via devel wrote: > On 21.05.2021 08:24, Zdenek Dohnal wrote: >> If your printer is network printer released approx. 2010 and later or >> USB printer released approx. 2015 and later (tips how to find out if >> your device supports driverless printing here [4]), you don't even >> need to install your printer anymore, not mention using a printer >> driver (or future printer applications). > > What about "win-printers" like HP LajerJet P1102w? > > Currently I maintain and use foo2zjs to use them without the > proprietary "plugins" from hplip. > -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Stephen John Smoogen wrote: > On Fri, May 21, 2021 at 18:19 Kevin Kofler via devel < > devel@lists.fedoraproject.org> wrote: > > > Zdenek Dohnal wrote: > > > The purpose of the library is have a way how to implement a support for > > > devices which don't support IPP Everywhere [2] or its derivations > > > (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can > > > be seen by CUPS once we remove printer driver support. > > > > I really don't see how the switch from drivers to printer applications is > > an > > improvement. All the existing drivers have to be ported to the new > > interface > > to essentially emulate the IPP protocol. > > Yes it is a bad situation but I don’t think there are a set of ‘CUPS’ > developers versus one person trying to keep the software going. Apple > stopped supporting the product and msweet is working for himself now. > lprint seems to be a ‘make a best out of a bad situation’. So what I'm hearing is that Fedora will soon stop working with my printer, because if there isn't enough manpower to even keep existing printer drivers in place, then who is going to write a bunch of pappls for not-quite-brand-new printers? And if the bright and shiny future is that USB printers look just like network printers, and network printers just show up without any installation, then I'm starting to wonder how I will know whether I'm sending my sensitive document to my USB printer or to some impostor on a wifi network. I wish working software could just continue working. Obviously that's far too sane for this insane world. Björn Persson pgpN_tzgp_dVv.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On Fri, May 21, 2021 at 18:19 Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Zdenek Dohnal wrote: > > It is a library for printer applications [1], not a substitute for CUPS. > > CUPS is still present and is going to be. > > > > There will be more printer applications coming into Fedora > > (ps-printer-app f.e.) and one already is (lprint). > > > > > > The purpose of the library is have a way how to implement a support for > > devices which don't support IPP Everywhere [2] or its derivations > > (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can > > be seen by CUPS once we remove printer driver support. > > I really don't see how the switch from drivers to printer applications is > an > improvement. All the existing drivers have to be ported to the new > interface > to essentially emulate the IPP protocol. And now, instead of being able to > configure printer options through the existing graphical CUPS frontends > (or > just set them temporarily in the individual application, which most > applications support nowadays), you end up with a CLI as in the old lpr > days, e.g.: > https://www.msweet.org/lprint/lprint.html#printing-options > https://www.msweet.org/lprint/lprint.html#setting-default-options > or at best, a GUI provided by the printer application in some arbitrary > toolkit, which will likely be GTK for Gutenprint (forcing KDE Plasma users > to use a GTK application to configure their printer) and Qt for HPLIP > (forcing GNOME users to use a Qt application to configure their printer). > Instead of a standardized interface to configure printer options, every > printer application now has to reinvent its own one. > > From the end user perspective, the new approach brings only disadvantages. > From the driver developer perspective, it means a lot of porting work. The > only ones who will benefit are the CUPS developers, who will have > successfully outsourced their work to other projects that now have to do > their work for them. > Yes it is a bad situation but I don’t think there are a set of ‘CUPS’ developers versus one person trying to keep the software going. Apple stopped supporting the product and msweet is working for himself now. lprint seems to be a ‘make a best out of a bad situation’. I don’t know what any other alternatives there are as more and more printers seem to be wanting you to send your prints to some central web server they own and then will talk with your printer and print the task. Or they say they support the IPP but really its an app on your machine which just takes it and makes it something proprietary and trying to talk ipp to the printer fails. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
Zdenek Dohnal wrote: > It is a library for printer applications [1], not a substitute for CUPS. > CUPS is still present and is going to be. > > There will be more printer applications coming into Fedora > (ps-printer-app f.e.) and one already is (lprint). > > > The purpose of the library is have a way how to implement a support for > devices which don't support IPP Everywhere [2] or its derivations > (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can > be seen by CUPS once we remove printer driver support. I really don't see how the switch from drivers to printer applications is an improvement. All the existing drivers have to be ported to the new interface to essentially emulate the IPP protocol. And now, instead of being able to configure printer options through the existing graphical CUPS frontends (or just set them temporarily in the individual application, which most applications support nowadays), you end up with a CLI as in the old lpr days, e.g.: https://www.msweet.org/lprint/lprint.html#printing-options https://www.msweet.org/lprint/lprint.html#setting-default-options or at best, a GUI provided by the printer application in some arbitrary toolkit, which will likely be GTK for Gutenprint (forcing KDE Plasma users to use a GTK application to configure their printer) and Qt for HPLIP (forcing GNOME users to use a Qt application to configure their printer). Instead of a standardized interface to configure printer options, every printer application now has to reinvent its own one. From the end user perspective, the new approach brings only disadvantages. From the driver developer perspective, it means a lot of porting work. The only ones who will benefit are the CUPS developers, who will have successfully outsourced their work to other projects that now have to do their work for them. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 21.05.2021 08:24, Zdenek Dohnal wrote: If your printer is network printer released approx. 2010 and later or USB printer released approx. 2015 and later (tips how to find out if your device supports driverless printing here [4]), you don't even need to install your printer anymore, not mention using a printer driver (or future printer applications). What about "win-printers" like HP LajerJet P1102w? Currently I maintain and use foo2zjs to use them without the proprietary "plugins" from hplip. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 5/20/21 11:09 PM, Reon Beon via devel wrote: > Thoughts? > > https://src.fedoraproject.org/rpms/pappl It is a library for printer applications [1], not a substitute for CUPS. CUPS is still present and is going to be. There will be more printer applications coming into Fedora (ps-printer-app f.e.) and one already is (lprint). The purpose of the library is have a way how to implement a support for devices which don't support IPP Everywhere [2] or its derivations (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can be seen by CUPS once we remove printer driver support. Another way of usage can be for printer vendors which find IPP Everywhere as a too much generic support for their devices, so they can implement their own printer application with more specialized options and that printer application will advertise the device to CUPS. _The bottom line of all of this:_ If your printer is network printer released approx. 2010 and later or USB printer released approx. 2015 and later (tips how to find out if your device supports driverless printing here [4]), you don't even need to install your printer anymore, not mention using a printer driver (or future printer applications). Since GTK is fixed (since F33), you can just open a print dialog, the device will be found (after you do several steps - here for network printers [1], USB printers [2]), and you can print. Printer applications will be needed only for older devices and specialized printing. [1] https://fedoraproject.org/wiki/How_to_debug_printing_problems#Printer_applications [2] https://www.pwg.org/ipp/everywhere.html [3] https://robots.org.uk/IPPOverUSB?action=AttachFile=view=IPP+USB+Specification.pdf [4] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_whether_my_printer_is_capable_of_driverless_printing.3F [5] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_network_printer [6] https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_setup_CUPS_temporary_queues_with_USB_printer > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Zdenek Dohnal Software Engineer Red Hat Czech - Brno TPB-C OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: When is pappl going to be good enough to replace cups?
On 2021-05-20 2:09 p.m., Reon Beon via devel wrote: Thoughts? https://src.fedoraproject.org/rpms/pappl My reading of that is that it's something that works with cups, not replaces it. Apparently we're supposed to use printer applications now instead of printer drivers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
When is pappl going to be good enough to replace cups?
Thoughts? https://src.fedoraproject.org/rpms/pappl ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
