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:nnnn where nnnn 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
