All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.