On Mon, 24 May 2021 at 12:29, Solomon Peachy <pizza@xxxxxxxxxxxx> 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@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
--
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.
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@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
