[Printing-architecture] Automatic printer setup with Printer Applications

Solomon Peachy pizza at shaftnet.org
Thu Feb 25 15:28:46 UTC 2021


On Wed, Feb 24, 2021 at 03:17:27PM +0100, Till Kamppeter wrote:
> You probably mean the USB quirks. This is to overcome hardware
> incompatibilities.

Yeah.  Not having something like this is responsible for most of the 
support headaches I get from MacOS users.

> For this we need support prioritization levels, like "generic" (CMD: item
> match), "third-party" (independent driver, like Gutenprint matches the model),
> "manufacturer" (manufacturer driver matches the model). 

"generic" is going to be so much so that I fear it will be effectively 
useless for autoconfiguration.  

Take Epson printers -- Nearly every model produced in over 25 years 
claims to support ESCP2, but there's very little beyond "print basic 
ASCII text" that one can ultimately rely on.  You need a more specific 
model family (dot matrix, mono-only inkjet, X color inkjet, etc) on top 
of that in order to be remotely useful for raster printing.

In other words, an application shouldn't claim "support" for a printer 
unless there's an explicit, positive match; everything else will require 
some sort of user/admin intervention/configuration.

I'm beginning to come around to the notion that we shouldn't even bother 
to create an automagic "figure out which printer application supports 
the printer just plugged in" mechanism, because it's going to take a 
_lot_ of work, it's nearly entirely an exercise in working around legacy 
baggage, and as Michael put it, we're not likely to ever see more than 
half a dozen printer applications anyway, and all of those will be 
focused around legacy models.

I don't see any printer makers bothering to create 
downloadable/runnable-on-end-user-systems printer applications for their 
art/speciality models (and definitely not for their legacy models) -- 
instead they'll sell a little "print server" that can be bolted onto the 
printer to achieve that functionality.

...and that "print server" will be running legacy CUPS (and hopefully, 
eventually, PAPPL) along with out-of-band scripts that detect the 
attached printers at startup time and create/export "queues" in a 
non-dynamic manner.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20210225/a34b123b/attachment.sig>


More information about the Printing-architecture mailing list