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 standardized protocols (and equally importantly, well-defined behaviors), Free Software reference implementations and conformance tests. Of course we also have bugs galore, because it's software. We have clients that can't conceive of a printer that uses non-office-sized paper, or that printers might have a duplexer. We have clients that crash when they're handed too many options. We have printers that always report success or will keel over if you specify attributes in a different order than the conformance test. We have clients that won't ever get updated, and printers that won't ever get updated. And through it all, users that just want to print something, and get quite irate when it inevitally goes sideways: https://tapas.io/episode/457149 - Solomon -- Solomon Peachy pizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (freenode)
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
