From: Solomon Peachy <pizza@shaftnet.org>
To: Till Kamppeter <till.kamppeter@gmail.com>
Cc: Open Printing <printing-architecture@lists.linux-foundation.org>,
Jai Luthra <luthrajaiji@gmail.com>
Subject: Re: [Printing-architecture] Automatic printer setup with Printer Applications
Date: Thu, 25 Feb 2021 10:28:46 -0500 [thread overview]
Message-ID: <YDfCLhAuxSbro6Ug@shaftnet.org> (raw)
In-Reply-To: <bb88fef5-f33e-3ca9-14da-ca189116ce9f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2384 bytes --]
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)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-02-25 15:28 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-23 19:27 [Printing-architecture] Automatic printer setup with Printer Applications Till Kamppeter
2021-02-24 7:37 ` Johannes Meixner
2021-02-24 8:03 ` Zdenek Dohnal
2021-02-24 11:25 ` Till Kamppeter
2021-02-24 12:01 ` Johannes Meixner
2021-02-24 13:51 ` Till Kamppeter
2021-02-25 10:30 ` Johannes Meixner
2021-02-25 13:37 ` Till Kamppeter
2021-02-25 14:00 ` Johannes Meixner
2021-02-25 13:53 ` Michael Sweet
2021-02-24 12:48 ` Solomon Peachy
2021-02-24 14:01 ` Johannes Meixner
2021-02-24 17:23 ` Till Kamppeter
2021-02-26 9:17 ` Johannes Meixner
2021-02-24 14:17 ` Till Kamppeter
2021-02-25 15:28 ` Solomon Peachy [this message]
2021-02-25 22:54 ` Till Kamppeter
2021-02-26 14:59 ` Solomon Peachy
2021-02-25 8:28 ` Zdenek Dohnal
2021-02-25 14:54 ` Solomon Peachy
2021-02-26 10:03 ` Johannes Meixner
2021-02-26 12:28 ` Solomon Peachy
2021-02-27 21:07 ` Michael Sweet
2021-02-24 14:17 ` Michael Sweet
2021-02-24 14:46 ` Johannes Meixner
2021-02-24 18:47 ` Till Kamppeter
2021-02-24 17:40 ` Till Kamppeter
2021-02-24 17:48 ` Michael Sweet
2021-02-24 19:21 ` Till Kamppeter
2021-02-24 20:01 ` Michael Sweet
2021-02-24 20:15 ` Till Kamppeter
2021-02-25 8:52 ` Zdenek Dohnal
2021-02-25 9:24 ` Till Kamppeter
2021-02-25 9:54 ` Zdenek Dohnal
2021-02-25 13:43 ` Michael Sweet
2021-02-25 19:39 ` Till Kamppeter
2021-02-25 13:33 ` Michael Sweet
2021-02-25 15:24 ` Till Kamppeter
2021-02-25 15:30 ` Michael Sweet
2021-02-25 21:51 ` Till Kamppeter
2021-03-02 10:58 ` [Printing-architecture] Future of Printer Setup Tools Till Kamppeter
2021-03-02 12:04 ` Johannes Meixner
2021-03-02 22:52 ` Till Kamppeter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YDfCLhAuxSbro6Ug@shaftnet.org \
--to=pizza@shaftnet.org \
--cc=luthrajaiji@gmail.com \
--cc=printing-architecture@lists.linux-foundation.org \
--cc=till.kamppeter@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.