[Printing-architecture] Printing-architecture Digest, Vol 206, Issue 16

Fri Feb 26 13:16:30 UTC 2021

 I have a couple questions as a user.  (I have no special expertise other than having installed various printers on different distributions in different ways over the years.). Please feel free to disregard my email if it is not helpful.
First, take the following example.  I have several computers and non-IPP everywhere/Airprint/Mopria, etc. network printers (e.g., old HP Laserjet) in my house.  As I understand it, each computer could install a printer application for these printers that effectively shares them as IPP Everywhere printers.  I'm assuming that this would mean that the printer application could be made available for printing on iOS/Android.  But does that mean that one printer application would show up for each computer, so that there are multiple copies of the same printer application available to mobile?  And would these printer applications also show up on the other computers?  (For example, Debian currently gives me notifications that it has found and installed one particular network printer..  Would I be getting these notices for printer applications installed on other computers?) I suppose that the printer applications could be installed on only one computer, but then it would need to be on all the time for other computers to print to it.  Or is it anticipated that printer applications will only be made available locally?  Will there be a way to make printer applications available on the local network on an individual basis?  Or would it be all or nothing?  I realize that there are settings in the CUPS configuration files currently to make shared printers emulating AirPrint available locally (and that there are various views about whether this particular type of sharing should be supported).  But my understand is that such files would no longer be available to edit if this functionality is in a container.
Second, would it be possible for the printer applications to have assigned ports in a range so they can be easily found?  There could also be another range that is first come first served.  I realize that this would require coordination, and that there may be technical reasons why it would not work.
Thanks!
    On Friday, February 26, 2021, 07:00:10 AM EST, printing-architecture-request at lists.linux-foundation.org <printing-architecture-request at lists.linux-foundation.org> wrote:  

 Send Printing-architecture mailing list submissions to
    printing-architecture at lists.linux-foundation.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

or, via email, send a message with subject or body 'help' to
    printing-architecture-request at lists.linux-foundation.org

You can reach the person managing the list at
    printing-architecture-owner at lists.linux-foundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Printing-architecture digest..."

Today's Topics:

  1. Re: Automatic printer setup with Printer    Applications
      (Till Kamppeter)
  2. Re: Automatic printer setup with Printer Applications
      (Till Kamppeter)
  3. Re: Automatic printer setup with Printer Applications
      (Johannes Meixner)
  4. Re: Automatic printer setup with Printer Applications
      (Johannes Meixner)

----------------------------------------------------------------------

Message: 1
Date: Thu, 25 Feb 2021 22:51:28 +0100
From: Till Kamppeter <till.kamppeter at gmail.com>
To: Michael Sweet <msweet at msweet.org>
Cc: "printing-architecture at lists.linux-foundation.org"
    <printing-architecture at lists.linux-foundation.org>, Jai Luthra
    <luthrajaiji at gmail.com>
Subject: Re: [Printing-architecture] Automatic printer setup with
    Printer    Applications
Message-ID: <f6f434cd-f9ea-6943-f1ef-4db0cf7cf762 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 25/02/2021 16:30, Michael Sweet wrote:
>> Or if you do not want to call an external executable via command line, do IPP with libcups to create the queue (with driver selection "auto").
> 
> The challenge there is to find the right socket to talk to... :/

Yes, DNS-SD only reveals the host/port access. As every Printer 
Application which provides a web interface has a host/port, one could 
use it, but calling the command is probably the most universal.

    Till

------------------------------

Message: 2
Date: Thu, 25 Feb 2021 23:54:51 +0100
From: Till Kamppeter <till.kamppeter at gmail.com>
To: Solomon Peachy <pizza at shaftnet.org>
Cc: Open Printing <printing-architecture at lists.linux-foundation.org>,
    Jai Luthra <luthrajaiji at gmail.com>
Subject: Re: [Printing-architecture] Automatic printer setup with
    Printer Applications
Message-ID: <a0ebda19-80ab-48cf-9032-6d14208f3237 at gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 25/02/2021 16:28, Solomon Peachy wrote:
> 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.
>

Seems that CUPS has this USB quirk functionality only in the 
libusb-based incarnation of the USB backend not in the Darwin one which 
Mac OS uses. The idea of USB quirks comes from me, as Michael put up the 
first sketch of a libusb-based USB backend it did not work very well for 
me and I vastly improved it, especially also investigating how the usblp 
kernel module works and there was this USB quirk handling which I had 
overtaken into the backend. Michael has then improved it by putting the 
rules into an editable file.

>> 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.
> 

I agree.

> 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 the PostScript Printer Application this works better. A generic 
PostScript PPD file works with practically all PostScript printers, it 
only misses support of many printer features, like more than 2 or 3 
trays, exotic paper sizes, finishers, ...

> 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.
> 

In the PostScript Printer Application this would mean printers for which 
there is a corresponding PPD file for exactly this model.

> 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.
> 

Only for the users not being completely lost with a legacy printer, 
should we have at least some simple tool which detects printers and 
lists them and checks installed Printer Applications whether they 
support it, with an "Add" button for auto-adding it, and also a button 
for the printer entry which does searches like "Acme LaserStar 1000+" 
and "Acme Printer" on the Snap Store? (As long as we have no 
hardware-signature-based search, Printer Applications supporting a few 
models could list them in their store listing's description, and a 
manufacturer's Printer Application always contains the manufacturer's 
name and "printer" somewhere in its title and/or description).

If we have the DNS-SD service lister which I mentioned in other postings 
on Printer Applications there could be besides the web interface and IPP 
System Service buttons also an auto-add button.

> 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.

OK, let's see.

    Till

------------------------------

Message: 3
Date: Fri, 26 Feb 2021 10:17:25 +0100
From: Johannes Meixner <jsmeix at suse.de>
To: printing-architecture at lists.linux-foundation.org
Subject: Re: [Printing-architecture] Automatic printer setup with
    Printer Applications
Message-ID: <226dd237ebac1b695eec291314ae22e3 at suse.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hello,

On 2021-02-24 18:23, Till Kamppeter wrote:
> On 24/02/2021 15:01, Johannes Meixner wrote:
>> 
>> I took me some longer time of experience what works
>> reasonably well in practice out there in real world
>> how to auto-match based on the manufacturer & model
>> strings which is the only data that is always there.
> 
> I go a similar way, matching by make and model
...
> What I do is taking the observed make and model,
> normalizing it to some form
...
> The names in the list of supported models
> I normalize the same way.

I did same i.e.
normalizing make and model what the system reports and
normalizing make and model in the PPDs in the same way,
then some "fuzzy match" to get a list of PPDs
that "somehow match" the reported make and model
with some "special sorting" to put the "somehow best match"
on top of that list and
finally show that list to the user so he can select one.

In automated setup case the topmost entry of that list
is used.

I vaguely described that in
https://en.opensuse.org/YaST_Printer#Driver

By the way 1:
For my general point of view about
"Automated Printer Configuration" see
https://en.opensuse.org/YaST_Printer#Automated_Printer_Configuration
versus the subsequent section
"Manual Printer Configuration with the YaST Printer Module"
therein.

By the way 2:
In practice the current "YaST Printer Module" is dead code, cf.
https://bugzilla.suse.com/show_bug.cgi?id=1175341#c1
I wished those who make the decisions would finally let it RIP.

Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

------------------------------

Message: 4
Date: Fri, 26 Feb 2021 11:03:34 +0100
From: Johannes Meixner <jsmeix at suse.de>
To: printing-architecture at lists.linux-foundation.org
Subject: Re: [Printing-architecture] Automatic printer setup with
    Printer Applications
Message-ID: <821b4df56f518b8d2cc38ce846e8cc48 at suse.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hello

On 2021-02-25 15:54, Solomon Peachy wrote (excerpts):
> 
> And much like we've seen multiple distinct models with
> identical USB VID/PIDs, I've also seen distinct models
> that share identical IEEE1284 IDs. [2]
> And then there's the iManufacturer/iModel/iSerial strings
> that may or may not match what's in the 1284 data
> or what's silkscreened onto the printer itself..
> ...Like everything else involving printing, it's a complete mess.
...
> [2] They are in the same family, but the PDL is barely incompatible..

for some (older) examples that "similar looking model names"
do not mean "same driver works" see the part about
"It is crucial to have exact model names!" in
https://en.opensuse.org/SDB:Purchasing_a_Printer_and_Compatibility

I do not agree that everything involving printing is a complete mess
but I do fully agree that model->driver matching is a complete mess
from which follows "automated printer setup is a complete mess"
so my personal conclusion is:

Stay away from automated printer setup
(unless you like complete mess ;-)

I am looking forward to the future where proper
IPP (Everywhere) printer devices provide all what is needed
(including spooling and handling many clients simultaneously)
so neither printer drivers (and their setup)
nor spooling services (and their setup)
are needed any longer.
Only clients that properly talk IPP directly to
IPP printer devices that properly provide IPP.

Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

------------------------------

Subject: Digest Footer

_______________________________________________
Printing-architecture mailing list
Printing-architecture at lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

------------------------------

End of Printing-architecture Digest, Vol 206, Issue 16
******************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20210226/88f637cf/attachment-0001.html>