On Mon, 24 May 2021 at 12:29, Solomon Peachy <pi...@shaftnet.org> 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: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. > > > 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 Peachy pizza at shaftnet dot org > (email&xmpp) > @pizza:shaftnet dot org (matrix) > High Springs, FL speachy (freenode) > _______________________________________________ > 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
