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)