[Printing-architecture] Automatic printer setup with Printer Applications

[Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

Hi,

one important feature for a good user experience with printing is the 
automatic setup of printers. at least locally connected (USB) printers 
either when they get plugged in and turned on or when their Printer 
Application gets installed and started.

The user expects this behavior, as in the current Linux distributions 
which use classic printer drivers consisting of PPD files and filters 
the locally connected printers also get their CUPS queue set up 
automatically and we do not want to loose this functionality when 
switching over to Printer Applications.

The first though here is to let the Printer Application, which is 
running as daemon observe the system for USB printers appearing or 
diappearing. This can be done using the hotplug functionality of libusb 
or with a UDEV monitor based on libudev (installing a UDEV rules file to 
make UDEV trigger a command execution does not work out of a Snap or 
other sandboxed packages). As soon as a new device appears the Printer 
Application would check whether it is supported by it and if so, create 
a print queue.

A proposed implementation is discussed as a Pull Request for the Printer 
Application support library PAPPL:

https://github.com/michaelrsweet/pappl/pull/36

There see especially my comment

https://github.com/michaelrsweet/pappl/pull/36#issuecomment-783533960

The main problem of this approach is that there can be many Printer 
Applications installed, especially with a desktop Linux distribution 
which should support as many different models of hardware as possible 
and therefore has practically all drivers available as free software 
installed. Once a new printer plugged in every Printer Application 
checks whether it supports it. Depending on how they do this this can 
cause a load peak for the system and also for the printer (if the 
Printer Application has to do additional queries on the decision whether 
the printer is supported).

So we need to do one or more of the following:

- Use the lowest impact method to observe device appearing and 
disappering. Is it libusb's hotplug or libudev's monitor?

- Lowest impact determining whether the appearing printer is supported, 
ideally letting the libusb/libudev process already grab the device ID 
and then run this device ID through PAPPL's auto-add callback function 
(this is the function with which each driver checks whether a printer is 
supported).

- Configurability of Printer Applications to turn off auto-setup and to 
blacklist selected printers, to avoid that there are more that one 
queues because a printer is supported by several Printer Applications.

- Reduce the number of Printer Applications which come with a Linux 
distribution by creating only one Printer Application which retro-fits 
all legacy printer drivers which are not maintained any more.

On a Debian or Ubuntu distribution you find all available printer 
drivers with the command line

apt search printer-driver | grep '^printer-driver-' | grep -v 
printer-driver-all | grep -v -- -common/ | cut -d / -f 1 | sed -e 
s/^printer-driver-//

which results in

brlaser
c2050
c2esp
cjet
cups-pdf
dymo
escpr
foo2zjs
fujixerox
gutenprint
hpcups
hpijs
indexbraille
m2300w
min12xxw
oki
pnm2ppa
postscript-hp
ptouch
pxljr
sag-gdi
splix

Take out hpcups, hpijs and postscript-hp and replace them by hplip. Also 
take out cups-pdf. Then we have 19 drivers and in addition we have 
foomatic which supports all built-in drivers of Ghostscript. Looking 
through the list there are many which are not maintained upstream any 
more: c2050, c2esp, cjet, m2300w, min12xxw, pnm2ppa, pxljr, sag-gdi, 
splix (and perhaps even more). They can all get joined into the Foomatic 
Printer Application, so we end up with a maximum of 11 Printer 
Applications. One needs to find out whether the impact of all of them on 
an appearing USB printer is too high or not.

An alternative approach would be to have a separate, external program to 
auto-setup printers instead of each Printer Application doing it 
individually, as we have currently /lib/udev/udev-configure-printer 
(part of system-config-printer) to auto-create CUPS queues with classic 
printer drivers. This program identifies the printer and assigns a 
driver supporting it, using a priority scheme if there is more than one 
suitable driver. One could proceed similarly for Printer Applications or 
even extend /lib/udev/udev-configure-printer for Printer Application 
support. This would especially also assure that only one print queue 
gets set up, independent of how many Printer Applications support the 
printer.

WDYT?

Should we take the centralized approach? Or should we let the Printer 
Applications do the auto setup individually?

Should we use libusb's hotplug approach or libudev's UDEV monitor 
approach to get notified of appearing and disappearing printers?

Any other thoughts?

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

Hello,

On 2021-02-23 20:27, Till Kamppeter wrote (excerpt):
> https://github.com/michaelrsweet/pappl/pull/36#issuecomment-783533960
.
.
.
> Should we take the centralized approach? Or should we let the Printer
> Applications do the auto setup individually?

I think both (i.e. centralized and individually) are needed.

Centralized:
The centralized method for the Linux distributor
to keep the default load low and
to ensure at most one queue is set up automatically
and optionally perhaps also to inform the user
(e.g. via whatever desktop notification system)
when no queue could be set up e.g. something like
"No driver found for 'ACME FancyPrinter 1000XL' but
  the Printer Application 'ACME_Fancy' is not installed."
when the Linux distribution provides a Printer Application
that looks as if it could provide the missing driver or
"No driver found for 'ACME FancyPrinter 1000XL'
  (Printer Application 'ACME_Fancy' does not list it)
  and no other matching Printer Application found."

Individually:
Let Printer Applications do the auto setup individually
for third-party Printer Applications (e.g. from printer
manufacturers that are possibly proprietary software).
The assumption is that end-users will not install many
third-party Printer Applications but only what they
actually need for their specific printer devices.
An interesting case could be a central print server in an
enterprise environment for many different office printers
where many different Printer Applications are needed.
I think that case is safe regarding USB hotplug load because
nobody connects office printers in enterprise environments
via USB at the central print server.
But I don't know how printer auto-setup behaves for network
printers (i.e. when there are very many DNS-SD announcements).


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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Zdenek Dohnal]

[-- Attachment #1.1: Type: text/plain, Size: 7244 bytes --]

Hi Till!

On 2/23/21 8:27 PM, Till Kamppeter wrote:
> Hi,
>
> one important feature for a good user experience with printing is the
> automatic setup of printers. at least locally connected (USB) printers
> either when they get plugged in and turned on or when their Printer
> Application gets installed and started.
>
> The user expects this behavior, as in the current Linux distributions
> which use classic printer drivers consisting of PPD files and filters
> the locally connected printers also get their CUPS queue set up
> automatically and we do not want to loose this functionality when
> switching over to Printer Applications.
Totally agree.
>
> The first though here is to let the Printer Application, which is
> running as daemon observe the system for USB printers appearing or
> diappearing. This can be done using the hotplug functionality of
> libusb or with a UDEV monitor based on libudev (installing a UDEV
> rules file to make UDEV trigger a command execution does not work out
> of a Snap or other sandboxed packages).

Ok, I did a quick search, udev rules don't work because /sys is a
read-only in Snap?

Then a service/daemon looks like a only way. Printer applications will
run as a service and udev-configure-printer is run as a service already,
but the udev rules must be removed and we need to add libusb/libudev
functionality into udev-configure-printer, if we are going to use it.

Do I understand it correctly?


> As soon as a new device appears the Printer Application would check
> whether it is supported by it and if so, create a print queue.
>
> A proposed implementation is discussed as a Pull Request for the
> Printer Application support library PAPPL:
>
> https://github.com/michaelrsweet/pappl/pull/36
>
> There see especially my comment
>
> https://github.com/michaelrsweet/pappl/pull/36#issuecomment-783533960
>
> The main problem of this approach is that there can be many Printer
> Applications installed, especially with a desktop Linux distribution
> which should support as many different models of hardware as possible
> and therefore has practically all drivers available as free software
> installed. Once a new printer plugged in every Printer Application
> checks whether it supports it. Depending on how they do this this can
> cause a load peak for the system and also for the printer (if the
> Printer Application has to do additional queries on the decision
> whether the printer is supported).

It just got on my mind (probably it will be nonsense) - what about
having only one printer application as a front door and a communication
point with other stuff in the system, and the other driver specific
stuff will be as a module, which could be loaded by one main printer
application, which would do the registering in MDNS and communication
with USB, so hammering USB ports could be prevented.

Even users can be happy that they don't need to install
'foomatic-printerapp' for this printer, 'hplip-printerapp' for other
printer, and they can just install 'generic-printerapp' and if they
don't care about installing all drivers (iiuc our CUPS snap integrates
all drivers anyway...) the modules will be installed via weak deps. Who
cares about minimization, he can install without weak deps and find out
which module supports his printer.

I just got this thought because I'm thinking more about systemd
nowadays, so it would be kind of systemd-version for printing apps.

>
> So we need to do one or more of the following:
>
> - Use the lowest impact method to observe device appearing and
> disappering. Is it libusb's hotplug or libudev's monitor?
>
> - Lowest impact determining whether the appearing printer is
> supported, ideally letting the libusb/libudev process already grab the
> device ID and then run this device ID through PAPPL's auto-add
> callback function (this is the function with which each driver checks
> whether a printer is supported).
>
> - Configurability of Printer Applications to turn off auto-setup and
> to blacklist selected printers, to avoid that there are more that one
> queues because a printer is supported by several Printer Applications.
>
> - Reduce the number of Printer Applications which come with a Linux
> distribution by creating only one Printer Application which retro-fits
> all legacy printer drivers which are not maintained any more.
>
> On a Debian or Ubuntu distribution you find all available printer
> drivers with the command line
>
> apt search printer-driver | grep '^printer-driver-' | grep -v
> printer-driver-all | grep -v -- -common/ | cut -d / -f 1 | sed -e
> s/^printer-driver-//
>
> which results in
>
> brlaser
> c2050
> c2esp
> cjet
> cups-pdf
> dymo
> escpr
> foo2zjs
> fujixerox
> gutenprint
> hpcups
> hpijs
> indexbraille
> m2300w
> min12xxw
> oki
> pnm2ppa
> postscript-hp
> ptouch
> pxljr
> sag-gdi
> splix
>
> Take out hpcups, hpijs and postscript-hp and replace them by hplip.
> Also take out cups-pdf. Then we have 19 drivers and in addition we
> have foomatic which supports all built-in drivers of Ghostscript.
> Looking through the list there are many which are not maintained
> upstream any more: c2050, c2esp, cjet, m2300w, min12xxw, pnm2ppa,
> pxljr, sag-gdi, splix (and perhaps even more). They can all get joined
> into the Foomatic Printer Application, so we end up with a maximum of
> 11 Printer Applications. One needs to find out whether the impact of
> all of them on an appearing USB printer is too high or not.
>
> An alternative approach would be to have a separate, external program
> to auto-setup printers instead of each Printer Application doing it
> individually, as we have currently /lib/udev/udev-configure-printer
> (part of system-config-printer) to auto-create CUPS queues with
> classic printer drivers. This program identifies the printer and
> assigns a driver supporting it, using a priority scheme if there is
> more than one suitable driver. One could proceed similarly for Printer
> Applications or even extend /lib/udev/udev-configure-printer for
> Printer Application support. This would especially also assure that
> only one print queue gets set up, independent of how many Printer
> Applications support the printer.
>
> WDYT?
>
> Should we take the centralized approach? Or should we let the Printer
> Applications do the auto setup individually?
If the one big printer application system+modules is a complete
nonsense, I would go with at least putting all dead drivers into
foomatic printer application, and then update udev-configure-printer to
use libusb/libudev for checking USB device, and if found any, it will
contact a printer application via PAPPL API or (probably rather, it
looks like it is more popular) via DBUS message.
>
> Should we use libusb's hotplug approach or libudev's UDEV monitor
> approach to get notified of appearing and disappearing printers?
I would prefer libusb - IMO libudev is closer to HW, which IIUC is not
needed here, so libusb looks fine for us.
>
> Any other thoughts?
>
>    Till
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 24/02/2021 09:03, Zdenek Dohnal wrote:
> 
> Ok, I did a quick search, udev rules don't work because /sys is a
> read-only in Snap?
>

The problem is that the installation of a Snap cannot install a UDEV 
rules file (/lib/udev/rules.d/70-printers.rules) into the system.

> Then a service/daemon looks like a only way. Printer applications will
> run as a service and udev-configure-printer is run as a service already,
> but the udev rules must be removed and we need to add libusb/libudev
> functionality into udev-configure-printer, if we are going to use it.
> 

Yes, we need to do either use a UDEV monitor based on libudev or use the 
hotplug functionality of libusb. Then udev-configure-printer has to be a 
permanently running daemon and a function gets triggered on every event 
of a USB device appearing or disappearing. We need to check whether the 
device is an actual printer at first, without polling anything from the 
device, so that we do not hammer all kinds of USB devices. If it is a 
printer we can do further things like polling the device ID from it. 
Advantage of a centralized service is that there are not 10 or more 
Printer Applications polling the device ID at the same time.

So udev-configure-printer will get turned into a permanent daemon and if 
it detects a printer plug/unplug it does more or less what the former 
udev-configure-printer did, but instead of creating a queue on CUPS it 
creates one on a Printer Application.

> 
> It just got on my mind (probably it will be nonsense) - what about
> having only one printer application as a front door and a communication
> point with other stuff in the system, and the other driver specific
> stuff will be as a module, which could be loaded by one main printer
> application, which would do the registering in MDNS and communication
> with USB, so hammering USB ports could be prevented.
> 
> Even users can be happy that they don't need to install
> 'foomatic-printerapp' for this printer, 'hplip-printerapp' for other
> printer, and they can just install 'generic-printerapp' and if they
> don't care about installing all drivers (iiuc our CUPS snap integrates
> all drivers anyway...) the modules will be installed via weak deps. Who
> cares about minimization, he can install without weak deps and find out
> which module supports his printer.
> 
> I just got this thought because I'm thinking more about systemd
> nowadays, so it would be kind of systemd-version for printing apps.
> 

We must keep in mind that everything should work in Snaps. So as we 
cannot add CUPS filters and PPD files to an installed CUPS Snap we also 
cannot add some kind of "driver plugins" to a Printer Application (at 
least not by means of an installation of an additional Snap containing 
the driver/plugin).

> If the one big printer application system+modules is a complete
> nonsense, I would go with at least putting all dead drivers into
> foomatic printer application, and then update udev-configure-printer to
> use libusb/libudev for checking USB device, and if found any, it will
> contact a printer application via PAPPL API or (probably rather, it
> looks like it is more popular) via DBUS message.

Yes, we can go this way, especially stuffing all the old drivers into 
the Foomatic Printer Application.

udev-configure-printer will not connect to the Printer Application via 
D-Bus, as there is no appropriate interface (yet).

udev-configure-printer will need an interface at all Printer 
Applications where it can send a device ID and the Printer Application 
answers back whether it supports this printer (with driver name), and 
that without the Printer Application talking to the physical printers. 
This interface more or less calls the autoadd callback function of the 
Printer Application. This way udev-configure-printer will find out 
whether there is support for the printer and if yes, by which Printer 
Applications and then prioritize. Great would be if a Printer 
Application also could report back support level (generic, third-party, 
manufacturer, ...). It could perhaps also prioritize unknown Printer 
Applications as they are most probably from the manufacturer and not 
from the distro.

> I would prefer libusb - IMO libudev is closer to HW, which IIUC is not
> needed here, so libusb looks fine for us.

Yes, libusb has also the advantage that in the same action we can grab 
the device ID of the printer.

libudev has the advantage to support more than only USB, parallel for 
example. But do we have to support the parallel port? Or can we safely 
assume that computers on which we install a current distro do not have 
parallel ports any more?

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

Hello,

On 2021-02-24 12:25, Till Kamppeter wrote (excerpts)
> So udev-configure-printer will get turned into a
> permanent daemon and if it detects a printer plug/unplug
> it does more or less what the former udev-configure-printer
> did, but instead of creating a queue on CUPS it creates
> one on a Printer Application.
...
> We must keep in mind that everything should work in Snaps.
...
> udev-configure-printer will need an interface at all Printer
> Applications where it can send a device ID and the Printer Application
> answers back whether it supports this printer (with driver name), and
> that without the Printer Application talking to the physical printers.
> This interface more or less calls the autoadd callback function of the
> Printer Application. This way udev-configure-printer will find out
> whether there is support for the printer and if yes, by which Printer
> Applications and then prioritize. Great would be if a Printer
> Application also could report back support level (generic,
> third-party, manufacturer, ...). It could perhaps also prioritize
> unknown Printer Applications as they are most probably from the
> manufacturer and not from the distro.

if I understand it correctly the basic idea behind is
that for printer setup inside a container
(I use 'container' as generic name for any isolated environment
  that has no direct access to the outer world e.g. also chroot)
udev-configure-printer acts as proxy for outer world access.

This leads me to a - perhaps crazy - idea:
Why not having a general printer access proxy daemon
that is running on the container host for any printer access
that is needed from inside a container i.e. also for normal
printing operations?

I am not at all a container expert but as far as I know
the usual access method between inside a container and the
outer world happens via network so a "USB access proxy"
that runs on the container host should be accessible via
network from within the container.

But this leads to the next - perhaps even more crazy - idea:
Why not having a USB printer wrapper daemon running on the
container host that wraps a USB printer into a network printer
so that from within the container the Printing Application
sees only DNS-SD announced network printers?


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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

On Wed, Feb 24, 2021 at 12:25:48PM +0100, Till Kamppeter wrote:
> udev-configure-printer will need an interface at all Printer Applications
> where it can send a device ID and the Printer Application answers back
> whether it supports this printer (with driver name), and that without the
> Printer Application talking to the physical printers. 

I wanted to add a comment here -- We need to think about what happens if 
multiple applications claim to support the printer, either because more 
than one genuinely does, or because of wildcard catch-all rules for 
"generic PCL" (or whatever) that could bind to any device exporting a 
USB Printer Class endpoint, much like the current CUPS backend.

The CUPS backend supports a blacklist so it can exclude printers, but 
given that printer applications can't drop files outside their sandbox, 
a new mechanism would need to be devised.  

> Great would be if a Printer Application also could report back support 
> level (generic, third-party, manufacturer, ...). It could perhaps also 
> prioritize unknown Printer Applications as they are most probably from 
> the manufacturer and not from the distro.

I don't know if there's any reasonable priority rules we could apply 
that would always yield the "correct" choice.  Except perhaps to put 
"generic" options at the bottom, but even if those generic options are 
the only ones available, the odds are they won't actually function 
properly anyway.

BTW, current (RHEL/Fedora) distro practice is to extract the complete 
list of supported printers at "printer driver packaging" time, and use 
that to figure out what package needs to be installed at runtime.  IIRC 
this exclusively uses IEEE1284 IDs.

And as a depressing data point, Gutenprint only has IEEE1284 IDs for 
about 15% of its supported models, and USB VID/PIDs for about 3%.  So a 
mechanism to auto-match based on the Manufacturer & Model strings out of 
the USB or IEEE1284 descriptors would still be a good idea..

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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 24/02/2021 13:01, Johannes Meixner wrote:
> 
> if I understand it correctly the basic idea behind is
> that for printer setup inside a container
> (I use 'container' as generic name for any isolated environment
>   that has no direct access to the outer world e.g. also chroot)
> udev-configure-printer acts as proxy for outer world access.
>

No, each container (Printer Application) has access to the printers and 
with the two methods I described can observe whether a printer is coming 
or going.

The central utility is to avoid that each installed container is queries 
a newly connected printer at the same time, overloading the printer, 
having race conditions who gets an answer and who not, ... The central 
utility would query the newly connected printer once and then talk to 
one container to create a print queue.

Note that the containers do are not able to talk to each other to 
negotiate which one gets the printer, they even do not know about the 
presence of their competitors for a given printer.

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

Hello,

On 2021-02-24 13:48, Solomon Peachy wrote (excerpt):
> And as a depressing data point, Gutenprint only has
> IEEE1284 IDs for about 15% of its supported models, and
> USB VID/PIDs for about 3%.  So a mechanism to auto-match
> based on the Manufacturer & Model strings out of the USB
> or IEEE1284 descriptors would still be a good idea..

I had experienced in the past some overenthusiastic
"let's simply just collect printer IEEE1284 IDs" or
"let's simply just collect printer USB VID/PIDs"
attempts by overenthusiastic wishful-thinkers
that appeared every now and then but never ever it
resulted really useful data - only duplicates for
well know printer devices like some HP LaserJets
but basically nothing for all those zillions of
printer devices that manufacturers continuously spill out
and unexperienced end-users "just buy" in the next shop.

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.

So a 90% working auto-match based on the manufacturer & model
works in 90% of the cases in practice out there in real world
while a 100% working auto-match based on IEEE1284 IDs or
USB VID/PIDs works only in less than about 20% of the
cases in practice out there in real world.

My auto-match based on the manufacturer & model strings
is in SUSE's YaST2 printer module in somewhat human readable
form only in my old YCP code (the new autogenerated Ruby code
is no longer actually human readable - at least not for me).

I could try to dig that out but I fear what comes out is a pile
of hacks that I just somehow put together to make that stuff
work reasonably well in practice out there in real world.


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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

Till,

> On Feb 23, 2021, at 2:27 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> Hi,
> 
> one important feature for a good user experience with printing is the automatic setup of printers. at least locally connected (USB) printers either when they get plugged in and turned on or when their Printer Application gets installed and started.

I'm torn on this, as nearly all currently shipping printers support AirPrint and/or IPP Everywhere.  There are still a couple outliers in the desktop printing arena at the very low end (!) but mobile (Android, iOS, iPadOS), ChromeOS, macOS, and Windows 10 have driven vendors to support the standards we've been working so hard on for the past 20+ years.  So that leaves supporting "legacy" printers for people that haven't bought a new printer in 10 years as well as special-use printers like the Epson/HP/Canon large format inkjets and the various label printers (which are starting to come around...)

Right now, the *expected* behavior is that the user has a compatible IPP printer and they don't need any special software for it.  The *exception* is that a user has a printer that needs extra software.  And setting up a printer (with whatever software) is not a common occurrence for most people - ordinary users do not operate a printer testing lab or go out to buy every new printer that comes out.

So I'm not thinking we need to go out of our way to engineer an efficient solution for adding a printer, and as Solomon notes I doubt we have enough information to make such a solution work.

Probably the best approach is to build a "registry" of manufacturers and command sets that each printer application supports. Then when a printer is connected or discovered, the desktop tool can:

    IPP Everywhere Printer?  ---> YES, we are done
        |
        | NO
        v
    < Which Printer Application(s) supports this manufacturer or command-set? >
        |
        v
    Is the Printer Application installed?  --> YES, do auto-add
        |
        | NO
        v
    Does the user want to install the Printer Application?  --> YES, install and auto-add
        |
        | NO
        v
    Cry in beer


Note: I am fully aware that in the photo/art printing arena there are people that will still want to use Gutenprint or other special purpose software rather than the standard IPP interface - that's fine, and that is what the Printer Application is for in the long term. But those users are "experts" and will know how to install the application and configure it for their printer.

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 24/02/2021 13:48, Solomon Peachy wrote:
> On Wed, Feb 24, 2021 at 12:25:48PM +0100, Till Kamppeter wrote:
>> udev-configure-printer will need an interface at all Printer Applications
>> where it can send a device ID and the Printer Application answers back
>> whether it supports this printer (with driver name), and that without the
>> Printer Application talking to the physical printers.
> 
> I wanted to add a comment here -- We need to think about what happens if
> multiple applications claim to support the printer, either because more
> than one genuinely does, or because of wildcard catch-all rules for
> "generic PCL" (or whatever) that could bind to any device exporting a
> USB Printer Class endpoint, much like the current CUPS backend.
> 

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). The 
Printer Application must tell udev-configure-printer with which level it 
supports the printer.

> The CUPS backend supports a blacklist so it can exclude printers, but
> given that printer applications can't drop files outside their sandbox,
> a new mechanism would need to be devised.
> 

You probably mean the USB quirks. This is to overcome hardware 
incompatibilities.

> I don't know if there's any reasonable priority rules we could apply
> that would always yield the "correct" choice.  Except perhaps to put
> "generic" options at the bottom, but even if those generic options are
> the only ones available, the odds are they won't actually function
> properly anyway.
> 
> BTW, current (RHEL/Fedora) distro practice is to extract the complete
> list of supported printers at "printer driver packaging" time, and use
> that to figure out what package needs to be installed at runtime.  IIRC
> this exclusively uses IEEE1284 IDs.
> 
> And as a depressing data point, Gutenprint only has IEEE1284 IDs for
> about 15% of its supported models, and USB VID/PIDs for about 3%.  So a
> mechanism to auto-match based on the Manufacturer & Model strings out of
> the USB or IEEE1284 descriptors would still be a good idea..

Here we also need to use make/model matching, independent whether we 
have the make/model from a device ID or not.

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

Hello,

On 2021-02-24 15:17, Michael Sweet wrote (excerpt):
> Right now, the *expected* behavior is that the user
> has a compatible IPP printer and they don't need any
> special software for it.  The *exception* is that a user
> has a printer that needs extra software.
...
> Note: I am fully aware that in the photo/art printing arena
> there are people that will still want to use Gutenprint
> or other special purpose software rather than the
> standard IPP interface - that's fine, and that is what
> the Printer Application is for in the long term.
> But those users are "experts" and will know how to install
> the application and configure it for their printer.

I like to add that in enterprise environments
automated printer setup is almost never needed.

So nowadays any further efforts for automated printer setup
could be mostly a waste of time - time that could be better
spend elsewhere (even if that is just more time for beer ;-)

The more I think about it the more I like the idea
to deprectate all printer setup tools and related stuff
except what CUPS itself provides.

For the exceptional cases only documentation should be sufficient
like "when you have 'ACME SpecialPrinter XL' do this and that".


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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 24/02/2021 15:01, Johannes Meixner wrote:
> I had experienced in the past some overenthusiastic
> "let's simply just collect printer IEEE1284 IDs" or
> "let's simply just collect printer USB VID/PIDs"
> attempts by overenthusiastic wishful-thinkers
> that appeared every now and then but never ever it
> resulted really useful data - only duplicates for
> well know printer devices like some HP LaserJets
> but basically nothing for all those zillions of
> printer devices that manufacturers continuously spill out
> and unexperienced end-users "just buy" in the next shop.
> 
> 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.
> 
> So a 90% working auto-match based on the manufacturer & model
> works in 90% of the cases in practice out there in real world
> while a 100% working auto-match based on IEEE1284 IDs or
> USB VID/PIDs works only in less than about 20% of the
> cases in practice out there in real world.
> 
> My auto-match based on the manufacturer & model strings
> is in SUSE's YaST2 printer module in somewhat human readable
> form only in my old YCP code (the new autogenerated Ruby code
> is no longer actually human readable - at least not for me).
> 
> I could try to dig that out but I fear what comes out is a pile
> of hacks that I just somehow put together to make that stuff
> work reasonably well in practice out there in real world.
> 

I go a similar way, matching by make and model, as we do not have device 
IDs and VID/PID for all printers (and there is a bunch of older Epsons 
all having the same VID/PID despite being different models).

What I do is taking the observed make and model, normalizing it to some 
form how a human would read it: all lowercase, any amount of 
non-alphanumeric characters replaced by a single separator character, a 
separator character between words, where a word boundary is any group of 
non-alphanumeric characters, a transition between letter and digit or 
digit and letter, and '+' is replaced by the word "plus", as model names 
often differ by an added '+'. The separator usually is space or '-', 
ending up that the resulting string only contains letters, digits, and 
the separator character. We also add mssing manufacturer names by known 
model names, remove different representations of the same manufacturer, ...

Examples:

HP LaserJet 4500 -> hp--lasejet-4500
Hewlett Packard laserjet 2+ -> hp--laserjet-2-plus
ecosys 1800s -> kyocera--ecosys-1800-s

The names in the list of supported models I normalize the same way.

So if we do not have the exact writing of a make/model name as of a 
device ID but a less exact writing of a third-party driver developer for 
example, the normalized strings will most probably match, but false 
matches are not very probable, as manufacturers would not market two 
different models whose names sound the same, for example names only 
differing by upper/lowercase or by non-alphanumeric characters.

The code for this, as I use it in the PostScript Printer Application 
(https://github.com/OpenPrinting/ps-printer-app) is in the 
libcupsfilters library:

https://github.com/OpenPrinting/cups-filters/blob/26770bc5690e950767e3dffc70b5231937e0a2ca/cupsfilters/ieee1284.c#L618

It has also functionality to normalize for sorted lists, replacing each 
group of digits by a number zero-padded to 6 digits.

My algorithm work for prioritizing drivers is in scp-dbus-service, of 
system-config-printer:

https://github.com/OpenPrinting/system-config-printer/blob/master/scp-dbus-service.py

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

In principle you are right, but

- We will get a lot of user complaints that something which worked 
before does not work any more, but probably we must somehow inform the 
users that if they have a legacy printer they have to set it up in a web 
interface.

- If there are many Printer Applications installed simultaneously 
(distro which wants to support everything) there are many web interfaces 
on https://localhost:80XX/ where the user has to find the right one to 
set up his printer. In addition, these many Printer Applications are 
racing for a port number on every boot, meaning that the Printer 
Applications are on different ports everytime. CUPS copes with this, as 
it uses DNS-SD-service-name-based URIs, but a user will not find the 
correct web interface when he wants to change something.

Probably distros should not ship Printer Applications and users should 
install from the Snap Store the ones they need, but then we would need this:

https://forum.snapcraft.io/t/hardware-associated-snaps-snap-store-search-by-hardware-signature/

Or the classic printer setup tool (in GNOME Control Center for example) 
should be replaced by something which lists all available IPP servers 
(this includes driverless network printers and also installed Printer 
Applications) with for each list entry two buttons, one leading to the 
web interface and one opening an IPP System Service status/config 
window. This way the user finds the correct web interface without 
knowing the port.

    Till


On 24/02/2021 15:17, Michael Sweet wrote:
> I'm torn on this, as nearly all currently shipping printers support AirPrint and/or IPP Everywhere.  There are still a couple outliers in the desktop printing arena at the very low end (!) but mobile (Android, iOS, iPadOS), ChromeOS, macOS, and Windows 10 have driven vendors to support the standards we've been working so hard on for the past 20+ years.  So that leaves supporting "legacy" printers for people that haven't bought a new printer in 10 years as well as special-use printers like the Epson/HP/Canon large format inkjets and the various label printers (which are starting to come around...)
> 
> Right now, the *expected* behavior is that the user has a compatible IPP printer and they don't need any special software for it.  The *exception* is that a user has a printer that needs extra software.  And setting up a printer (with whatever software) is not a common occurrence for most people - ordinary users do not operate a printer testing lab or go out to buy every new printer that comes out.
> 
> So I'm not thinking we need to go out of our way to engineer an efficient solution for adding a printer, and as Solomon notes I doubt we have enough information to make such a solution work.
> 
> Probably the best approach is to build a "registry" of manufacturers and command sets that each printer application supports. Then when a printer is connected or discovered, the desktop tool can:
> 
>      IPP Everywhere Printer?  ---> YES, we are done
>          |
>          | NO
>          v
>      < Which Printer Application(s) supports this manufacturer or command-set? >
>          |
>          v
>      Is the Printer Application installed?  --> YES, do auto-add
>          |
>          | NO
>          v
>      Does the user want to install the Printer Application?  --> YES, install and auto-add
>          |
>          | NO
>          v
>      Cry in beer
> 
> 
> Note: I am fully aware that in the photo/art printing arena there are people that will still want to use Gutenprint or other special purpose software rather than the standard IPP interface - that's fine, and that is what the Printer Application is for in the long term. But those users are "experts" and will know how to install the application and configure it for their printer.

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

Till,

> On Feb 24, 2021, at 12:40 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> In principle you are right, but
> 
> - We will get a lot of user complaints that something which worked before does not work any more, but probably we must somehow inform the users that if they have a legacy printer they have to set it up in a web interface.

I never claimed that you shouldn't try to provide a good user experience, just that I don't think you need to hyper-optimize something that is only done once.

> - If there are many Printer Applications installed simultaneously (distro which wants to support everything) there are many web interfaces on https://localhost:80XX/ where the user has to find the right one to set up his printer. In addition, these many Printer Applications are racing for a port number on every boot, meaning that the Printer Applications are on different ports everytime. CUPS copes with this, as it uses DNS-SD-service-name-based URIs, but a user will not find the correct web interface when he wants to change something.

... which is why I suggested you create a registry for printer applications so that you can map a printer to one or more printer applications that you then run "autoadd" on.

I *don't* think that users should have every printer application installed - that is wasteful and confusing.

> ...
> Or the classic printer setup tool (in GNOME Control Center for example) should be replaced by something which lists all available IPP servers (this includes driverless network printers and also installed Printer Applications) with for each list entry two buttons, one leading to the web interface and one opening an IPP System Service status/config window. This way the user finds the correct web interface without knowing the port.

If the printer applications are based on PAPPL, you can use DNS-SD to find their system service endpoints and then have them add the printer using standard IPP operations, all through a common GUI.  Similarly, you can use DNS-SD to find the web pages, if that is the way you want to go...

________________________
Michael Sweet

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 24/02/2021 15:46, Johannes Meixner wrote:
> 
> I like to add that in enterprise environments
> automated printer setup is almost never needed.
>

Yes, that is true.

All about automatic print queue creation with Printer Applications is 
for end-user-oriented desktop distros.

> So nowadays any further efforts for automated printer setup
> could be mostly a waste of time - time that could be better
> spend elsewhere (even if that is just more time for beer ;-)
> 
> The more I think about it the more I like the idea
> to deprectate all printer setup tools and related stuff
> except what CUPS itself provides.
> 
> For the exceptional cases only documentation should be sufficient
> like "when you have 'ACME SpecialPrinter XL' do this and that".
> 

Yes, I am also in favor of deprecating the classic printer setup tool.

Instead, we need the following:

1. A local/network service manager (could be an item of GNOME Control 
Center): Take avahi-discover. It lists a lot of services, local (Avahi 
0.8.x+) and network services, sorted by network interface, then by 
service type. The tool I have in mind should list them in a 
user-friendly way, so that one sees for example a Printer Application, 
shows some property info like printing/scanning/faxout, button to open 
web interface, button to open IPP System Service status/config panel, 
list of printers (and scanners) with properties like size class (A4, A3, 
larger, smaller, ...), color/gray, duplex, ... Also useful entries for 
services which are no Printer Applications (for example your router, no 
need to know its IP, you have a button for its web interface now). All 
info needed by this tool comes from DNS-SD (Avahi on Linux).

2. A "driver finder": A tool which helps you to find the correct Printer 
Application if you have Acme LaserStar 1000+ and this is not a 
driverless printer. It more or less guides the user through the scheme 
of Michael's posting in this thread.

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 24/02/2021 18:48, Michael Sweet wrote:
> 
> ... which is why I suggested you create a registry for printer applications so that you can map a printer to one or more printer applications that you then run "autoadd" on.
>

Printer Applications should have a way to query the full list of 
printers they support by model and also the full list of generic (for 
example by-PDL) support options they have. So some "Printer Application 
finder" tool could find whether support for a certain printer is 
available and then add the printer (with driver "auto") on the right 
Printer Application.

> I *don't* think that users should have every printer application installed - that is wasteful and confusing.
>

I think so, too. The Printer Applications should be available in the 
Snap Store and the Snap Store should have the 
search-by-hardware-signature thingy which I suggested:

https://forum.snapcraft.io/t/hardware-associated-snaps-snap-store-search-by-hardware-signature/

> 
> If the printer applications are based on PAPPL, you can use DNS-SD to find their system service endpoints and then have them add the printer using standard IPP operations, all through a common GUI.  Similarly, you can use DNS-SD to find the web pages, if that is the way you want to go...

Yes, I was also thinking this way for the network/local service manager 
application I suggested in the other thread. The manager could also have 
a button to start the "Printer Application finder" at each Printer 
Application entry.

The "Printer Application finder" will, once the correct Printer 
Application is selected (and installed if it was not installed yet) 
actually set up the printer via IPP operations.

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

Till,

> On Feb 24, 2021, at 2:21 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 24/02/2021 18:48, Michael Sweet wrote:
>> ... which is why I suggested you create a registry for printer applications so that you can map a printer to one or more printer applications that you then run "autoadd" on.
>> 
> 
> Printer Applications should have a way to query the full list of printers they support by model and also the full list of generic (for example by-PDL) support options they have. So some "Printer Application finder" tool could find whether support for a certain printer is available and then add the printer (with driver "auto") on the right Printer Application.

The "drivers" sub-command from PAPPL almost has everything needed:

testsuite/testmainloop drivers
pwg_2inch-203dpi-black_1                PWG 2inch Label 203DPI Black
pwg_2inch-300dpi-black_1                PWG 2inch Label 300DPI Black
pwg_4inch-203dpi-black_1                PWG 4inch Label 203DPI Black
pwg_4inch-300dpi-black_1                PWG 4inch Label 300DPI Black
pwg_common-300dpi-black_1               PWG Office 300DPI Black
pwg_common-300dpi-sgray_8               PWG Office 300DPI sGray 8-bit
pwg_common-300dpi-srgb_8                PWG Office 300DPI sRGB 8-bit
pwg_common-300dpi-600dpi-black_1        PWG Office 300DPI 600DPI Black
pwg_common-300dpi-600dpi-sgray_8        PWG Office 300DPI 600DPI sGray 8-bit
pwg_common-300dpi-600dpi-srgb_8         PWG Office 300DPI 600DPI sRGB 8-bit
pwg_fail-300dpi-black_1                 PWG Always Fails 300DPI Black

hp-printer-app drivers
hp_deskjet                              HP DeskJet
hp_generic                              Generic PCL
hp_laserjet                             HP LaserJet

We can extend this to report the 1284 device IDs (which will give you make and model separate from the driver description string along with the command set(s)), and/or provide the information in a more machine-friendly format.

________________________
Michael Sweet




[-- Attachment #2: Type: text/html, Size: 3650 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 24/02/2021 21:01, Michael Sweet wrote:
> The "drivers" sub-command from PAPPL almost has everything needed:
> 
>     testsuite/testmainloop drivers
>     pwg_2inch-203dpi-black_1                PWG 2inch Label 203DPI Black
>     pwg_2inch-300dpi-black_1                PWG 2inch Label 300DPI Black
>     pwg_4inch-203dpi-black_1                PWG 4inch Label 203DPI Black
>     pwg_4inch-300dpi-black_1                PWG 4inch Label 300DPI Black
>     pwg_common-300dpi-black_1               PWG Office 300DPI Black
>     pwg_common-300dpi-sgray_8               PWG Office 300DPI sGray 8-bit
>     pwg_common-300dpi-srgb_8                PWG Office 300DPI sRGB 8-bit
>     pwg_common-300dpi-600dpi-black_1        PWG Office 300DPI 600DPI Black
>     pwg_common-300dpi-600dpi-sgray_8        PWG Office 300DPI 600DPI
>     sGray 8-bit
>     pwg_common-300dpi-600dpi-srgb_8         PWG Office 300DPI 600DPI
>     sRGB 8-bit
>     pwg_fail-300dpi-black_1                 PWG Always Fails 300DPI Black
> 
>     hp-printer-app drivers
>     hp_deskjet                              HP DeskJet
>     hp_generic                              Generic PCL
>     hp_laserjet                             HP LaserJet
> 
> 
> We can extend this to report the 1284 device IDs (which will give you 
> make and model separate from the driver description string along with 
> the command set(s)), and/or provide the information in a more 
> machine-friendly format.

Yes, this would be great. You could create some variants (options?) for 
the "drivers" subcommand, the current format, device ID added, only 
device ID plus driver name, every column in "..." for easy separation by 
a program, ... and the same things should be also queriable via IPP, so 
that a program does not need to run a client command line.

Device IDs could also inform about support level. An ID with make and 
model can provide an exact match to that printer which is higher 
priority than "genric" device IDs, like "CMD:POSTSCRIPT;" or 
"MFG:HP;CMD:PXL;".

    Till

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Zdenek Dohnal]

[-- Attachment #1.1: Type: text/plain, Size: 1047 bytes --]

On 2/24/21 1:48 PM, Solomon Peachy wrote:
> BTW, current (RHEL/Fedora) distro practice is to extract the complete
> list of supported printers at "printer driver packaging" time, and use 
> that to figure out what package needs to be installed at runtime.  IIRC 
> this exclusively uses IEEE1284 IDs.
>
> And as a depressing data point, Gutenprint only has IEEE1284 IDs for 
> about 15% of its supported models, and USB VID/PIDs for about 3%.  So a 
> mechanism to auto-match based on the Manufacturer & Model strings out of 
> the USB or IEEE1284 descriptors would still be a good idea..

Actually that's one of ideas to do in scp library (which is used by
scp-dbus-service and by udev-configure-printer) - allow parsing/parse on
Model/Manufacturer/Nickname strings instead of IEEE1284 strings.

Solomon, I'm sorry if it is an obvious fact, but I don't know it - would
you mind me asking why IEEE1284 IDs aren't used so much in drivers?

>
>  - Solomon

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Zdenek Dohnal]

[-- Attachment #1.1: Type: text/plain, Size: 3948 bytes --]

Hi Mike,

On 2/24/21 3:17 PM, Michael Sweet wrote:
> Till,
>
>> On Feb 23, 2021, at 2:27 PM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
>>
>> Hi,
>>
>> one important feature for a good user experience with printing is the automatic setup of printers. at least locally connected (USB) printers either when they get plugged in and turned on or when their Printer Application gets installed and started.
> I'm torn on this, as nearly all currently shipping printers support AirPrint and/or IPP Everywhere.  There are still a couple outliers in the desktop printing arena at the very low end (!) but mobile (Android, iOS, iPadOS), ChromeOS, macOS, and Windows 10 have driven vendors to support the standards we've been working so hard on for the past 20+ years.  So that leaves supporting "legacy" printers for people that haven't bought a new printer in 10 years as well as special-use printers like the Epson/HP/Canon large format inkjets and the various label printers (which are starting to come around...)
>
> Right now, the *expected* behavior is that the user has a compatible IPP printer and they don't need any special software for it.  The *exception* is that a user has a printer that needs extra software.  And setting up a printer (with whatever software) is not a common occurrence for most people - ordinary users do not operate a printer testing lab or go out to buy every new printer that comes out.
>
> So I'm not thinking we need to go out of our way to engineer an efficient solution for adding a printer, and as Solomon notes I doubt we have enough information to make such a solution work.
>
> Probably the best approach is to build a "registry" of manufacturers and command sets that each printer application supports. Then when a printer is connected or discovered, the desktop tool can:
>
>     IPP Everywhere Printer?  ---> YES, we are done
>         |
>         | NO
>         v
>     < Which Printer Application(s) supports this manufacturer or command-set? >
>         |
>         v
>     Is the Printer Application installed?  --> YES, do auto-add
>         |
>         | NO
>         v
>     Does the user want to install the Printer Application?  --> YES, install and auto-add
>         |
>         | NO
>         v
>     Cry in beer

Sounds reasonable, except for crying in beer! That's never reasonable
around here :D

So udev-configure-printer would:

1) check if there is a USB device - if it is IPP-over-USB and isn't in
allow list (probably there will be devices which will present themselves
as IPP-over-USB, but it will be broken, so they want to fall back to
printer application...), break out

2) find a printer application which supports the device

3) if it is not installed, install it - this will need to be updated -
currently PackageKit is used in scp lib, but PackageKit is going away in
the future [1] - I heard there is some work in DNF regarding PackageKit
functionality, but I'm not sure how far they are. Not mentioning it is a
distro specific package manager, not sure if other distros have already
some alternative to PackageKit.

4) auto-add the device to a printer application - scp lib for adding
print queues is now for CUPS only and written in Python, so it will need
to be rewritten in C/Go using PAPPL.


[1]
https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/

>
>
> Note: I am fully aware that in the photo/art printing arena there are people that will still want to use Gutenprint or other special purpose software rather than the standard IPP interface - that's fine, and that is what the Printer Application is for in the long term. But those users are "experts" and will know how to install the application and configure it for their printer.
>
> ________________________
> Michael Sweet
>
>
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 25/02/2021 09:52, Zdenek Dohnal wrote:
> Sounds reasonable, except for crying in beer! That's never reasonable
> around here :D
> 
> So udev-configure-printer would:
> 
> 1) check if there is a USB device - if it is IPP-over-USB and isn't in
> allow list (probably there will be devices which will present themselves
> as IPP-over-USB, but it will be broken, so they want to fall back to
> printer application...), break out
> 
> 2) find a printer application which supports the device
> 
> 3) if it is not installed, install it - this will need to be updated -
> currently PackageKit is used in scp lib, but PackageKit is going away in
> the future [1] - I heard there is some work in DNF regarding PackageKit
> functionality, but I'm not sure how far they are. Not mentioning it is a
> distro specific package manager, not sure if other distros have already
> some alternative to PackageKit.
>

Here we should not only consider distro-specific RPM and DEB packages 
but also distro-independent packaging, like Snap, as Printer 
Applications should also serve for hardware manufacturers to easily 
create distro-independent driver packages, one for all.

Central repositories, like the Snap Store would need some 
hardware-signature-based search, see

https://forum.snapcraft.io/t/hardware-associated-snaps-snap-store-search-by-hardware-signature/

> 4) auto-add the device to a printer application - scp lib for adding
> print queues is now for CUPS only and written in Python, so it will need
> to be rewritten in C/Go using PAPPL.
> 

Zdenek, could you update your GSoC project idea if needed?

https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects#turn_the_scp-dbus-service_methods_-_getbestdrivers_and_missingexecutables_-_of_system-config-printer_into_c

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Zdenek Dohnal]

[-- Attachment #1.1: Type: text/plain, Size: 2553 bytes --]


On 2/25/21 10:24 AM, Till Kamppeter wrote:
> On 25/02/2021 09:52, Zdenek Dohnal wrote:
>> Sounds reasonable, except for crying in beer! That's never reasonable
>> around here :D
>>
>> So udev-configure-printer would:
>>
>> 1) check if there is a USB device - if it is IPP-over-USB and isn't in
>> allow list (probably there will be devices which will present themselves
>> as IPP-over-USB, but it will be broken, so they want to fall back to
>> printer application...), break out
>>
>> 2) find a printer application which supports the device
>>
>> 3) if it is not installed, install it - this will need to be updated -
>> currently PackageKit is used in scp lib, but PackageKit is going away in
>> the future [1] - I heard there is some work in DNF regarding PackageKit
>> functionality, but I'm not sure how far they are. Not mentioning it is a
>> distro specific package manager, not sure if other distros have already
>> some alternative to PackageKit.
>>
>
> Here we should not only consider distro-specific RPM and DEB packages
> but also distro-independent packaging, like Snap, as Printer
> Applications should also serve for hardware manufacturers to easily
> create distro-independent driver packages, one for all.
>
> Central repositories, like the Snap Store would need some
> hardware-signature-based search, see
>
> https://forum.snapcraft.io/t/hardware-associated-snaps-snap-store-search-by-hardware-signature/
>
I don't know about programming Snap installation from an application
right now, I'll search for some manuals. If you have any links about
programming it, please send them my way.
>
>> 4) auto-add the device to a printer application - scp lib for adding
>> print queues is now for CUPS only and written in Python, so it will need
>> to be rewritten in C/Go using PAPPL.
>>
>
> Zdenek, could you update your GSoC project idea if needed?
>
> https://wiki.linuxfoundation.org/gsoc/google-summer-code-2021-openprinting-projects#turn_the_scp-dbus-service_methods_-_getbestdrivers_and_missingexecutables_-_of_system-config-printer_into_c
>

IMO it can stay as it is - I wouldn't like to update the GSoC project
with more tasks and make it more complex, since the last GSoC project
wasn't implemented.

udev-configure-printer can use this project once it is implemented, so
IMO it is not a good idea to put udev-configure-printer there right now
since dbus-service is not implemented yet.

>
>    Till
>
-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

Hello,

I have a general understanding problem and questions
regarding how Printer Applications are meant to work.

In
https://openprinting.github.io/upcoming-technologies/01-printer-application/
I understand that a Printer Application emulates
a driverless IPP printer so that a printer device
appears to "others" as IPP Everywhere printer
which means "others" detect and communicate with
that (emulated) IPP Everywhere printer via network.

Basically a Printer Application "wraps" a printer device
into an IPP Everywhere network printer.

What I do not understand is how a Printer Application
detects and communicates with its associated
actual printer device

For example printers that have both a USB interface
and a network interface with several network protocols
like TCP socket, LPD, (dumb) IPP (no IPP Everywhere).

How does a Printer Application implement
detection and communication with such devices?

Does each and every Printer Application implement
it for each and every combination of methods?

Or in other words:
In traditional CUPS device detection and communication
was separated from the "driver" functionality by having
separated CUPS backends for different access methods
that are also separated from the other CUPS filters.
How is that done with Printer Applications?


On 2021-02-24 14:51, Till Kamppeter wrote:
> On 24/02/2021 13:01, Johannes Meixner wrote:
>> 
>> if I understand it correctly the basic idea behind is
>> that for printer setup inside a container
>> (I use 'container' as generic name for any isolated environment
>>   that has no direct access to the outer world e.g. also chroot)
>> udev-configure-printer acts as proxy for outer world access.
> 
> No, each container (Printer Application) has access to the printers
> and with the two methods I described can observe whether a printer
> is coming or going.

I am really not a container expert so I may ask obvious things:

I do not understand how a Printer Application that runs inside
a container "has access" to printer devices that exist outside
of the container - i.e. how something inside a container
"has access" to e.g. USB device nodes that should normally
be only accessible from the container host system?

Or in other words:
If "just installing" a containerized Printer Application
makes USB device nodes on the container host system
"just accessible" from within the container
I would consider this as a major security violation.
When I install a containerized application I would expect
that there are no automated holes in its isolation.
I think all holes in container isolation require explicit
user confirmation (at least I hope this is the standard).
E.g. I may have two USB printers (perhaps even two same models)
and I may want to allow access from within a containerized
Printer Application to only one exactly specified printer.


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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

Zdenek,

> On Feb 25, 2021, at 3:52 AM, Zdenek Dohnal <zdohnal@redhat.com> wrote:
> ..
> Sounds reasonable, except for crying in beer! That's never reasonable
> around here :D

:)

> So udev-configure-printer would:
> 
> 1) check if there is a USB device - if it is IPP-over-USB and isn't in
> allow list (probably there will be devices which will present themselves
> as IPP-over-USB, but it will be broken, so they want to fall back to
> printer application...), break out

Actually, I don't think you're going to find as many broken IPP-USB printers as you think since all but the first couple HP models  implemented IPP-USB to get AirPrint certification, which means it got tested extensively... :)

> 2) find a printer application which supports the device
> 
> 3) if it is not installed, install it - this will need to be updated -
> currently PackageKit is used in scp lib, but PackageKit is going away in
> the future [1] - I heard there is some work in DNF regarding PackageKit
> functionality, but I'm not sure how far they are. Not mentioning it is a
> distro specific package manager, not sure if other distros have already
> some alternative to PackageKit.

Up to you, but I would expect some user confirmation before installing any software on my computer...

> 4) auto-add the device to a printer application - scp lib for adding
> print queues is now for CUPS only and written in Python, so it will need
> to be rewritten in C/Go using PAPPL.

Why?  The printer application can just be run with the "autoadd" sub-command, no need to link against PAPPL for that.

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 25/02/2021 11:30, Johannes Meixner wrote:
> 
> Hello,
> 
> I have a general understanding problem and questions
> regarding how Printer Applications are meant to work.
> 
> In
> https://openprinting.github.io/upcoming-technologies/01-printer-application/ 
> 
> I understand that a Printer Application emulates
> a driverless IPP printer so that a printer device
> appears to "others" as IPP Everywhere printer
> which means "others" detect and communicate with
> that (emulated) IPP Everywhere printer via network.
> 
> Basically a Printer Application "wraps" a printer device
> into an IPP Everywhere network printer.
> 
> What I do not understand is how a Printer Application
> detects and communicates with its associated
> actual printer device
> 
> For example printers that have both a USB interface
> and a network interface with several network protocols
> like TCP socket, LPD, (dumb) IPP (no IPP Everywhere).
> 
> How does a Printer Application implement
> detection and communication with such devices?
> 
> Does each and every Printer Application implement
> it for each and every combination of methods?
> 
> Or in other words:
> In traditional CUPS device detection and communication
> was separated from the "driver" functionality by having
> separated CUPS backends for different access methods
> that are also separated from the other CUPS filters.
> How is that done with Printer Applications?
> 
> 

Each Printer Application contains the filter and backend functionality 
for the printers it supports.

The PostScript Printer Application which I have developed for example 
contains functionality to connect to USB printers and to TCP socket 
printers via appropriate device functions in PAPPL. PAPPL (and so also 
my Printer Application) does not support LPD and dumb IPP, as all known 
network printers also support TCP socket (and this is usually more 
reliable than the two others). PAPPL also supports discovery, via libusb 
for USB printers and both via DNS-SD and SNMP for TCP Socket.

The filtering from a driverless-typical standard format (PDF, Apple 
Raster, PWG Raster, JPG) to the printer's native format is also done by 
the Printer Application. For my PostScript application I use the code of 
the pdftops and pstops CUPS filters (converted into filter functions in 
libcupsfilters of cups-filters 2.x) and additional functions (using 
libppd of cups-filters 2.x) to convert PAPPL's raster data streams to 
PostScript.

To get the emulated IPP printer one needs to create a print queue in the 
Printer Application, via web interface, command line, or IPP.

> I am really not a container expert so I may ask obvious things:
> 
> I do not understand how a Printer Application that runs inside
> a container "has access" to printer devices that exist outside
> of the container - i.e. how something inside a container
> "has access" to e.g. USB device nodes that should normally
> be only accessible from the container host system?
> 
> Or in other words:
> If "just installing" a containerized Printer Application
> makes USB device nodes on the container host system
> "just accessible" from within the container
> I would consider this as a major security violation.
> When I install a containerized application I would expect
> that there are no automated holes in its isolation.
> I think all holes in container isolation require explicit
> user confirmation (at least I hope this is the standard).
> E.g. I may have two USB printers (perhaps even two same models)
> and I may want to allow access from within a containerized
> Printer Application to only one exactly specified printer.
> 

The containers are not completely closed. They have controlled 
connections to the outside, so-called interfaces. A Printer Application 
always has interfaces to open a port on the network, to register its 
services on DNS-SD, to provide a UNIX socket, and in addition, to access 
the printer hardware it supports, usually access to USB, to the network 
as a client, and perhaps also to UDEV.

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Till,

> On Feb 25, 2021, at 4:24 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> Central repositories, like the Snap Store would need some hardware-signature-based search, see
> 
> https://forum.snapcraft.io/t/hardware-associated-snaps-snap-store-search-by-hardware-signature/

That is certainly one approach, and if Canonical is going to provide some general support for finding snaps that support particular hardware (not just printers) then it makes sense.

That said, the number of printer applications is not likely to be huge (LPrint, hp-printer-app, and ps-printer-app make 3, and potential future HP-LIP and Gutenprint printer applications make 5), so even if you just maintained files with the latest "app-name drivers" output you'd be able to do a good job of mapping printers to printer applications.

Remember, Printer Applications are addressing a short term (~10 year?) need to support legacy printers, at which point the primary users will be "experts" that wouldn't use the default printer application/IPP Everywhere support anyways.  New printers almost universally support IPP (the outliers being for "experts").

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

Johannes,

> On Feb 25, 2021, at 5:30 AM, Johannes Meixner <jsmeix@suse.de> wrote:
> ...
> What I do not understand is how a Printer Application
> detects and communicates with its associated
> actual printer device

So in PAPPL I've essentially created the CUPS backend interface (renamed to "device") so that a Printer Application can discover USB and network (AppSocket) printers out-of-the-box, with hooks to support other protocols/technologies as needed.

> For example printers that have both a USB interface
> and a network interface with several network protocols
> like TCP socket, LPD, (dumb) IPP (no IPP Everywhere).
> 
> How does a Printer Application implement
> detection and communication with such devices?
> 
> Does each and every Printer Application implement
> it for each and every combination of methods?

PAPPL provides a common implementation for Printer Applications, and for network printing it only supports AppSocket due to IPP and LPD variability in older printers (i.e. AppSocket is the most reliable choice for old printers because the vendors couldn't screw it up...)

> Or in other words:
> In traditional CUPS device detection and communication
> was separated from the "driver" functionality by having
> separated CUPS backends for different access methods
> that are also separated from the other CUPS filters.
> How is that done with Printer Applications?

Printer Applications are "vertically integrated" 🤪

Basically, the goal is for a Printer Application to be a self-contained piece of software that doesn't depend on CUPS backends or filters.  Rather, since those things will eventually be going away it needs to expose a platform-agnostic interface (IPP Everywhere).

Whether an OS provides further isolation (Printer Application X can only access USB printer Y) is beyond the scope of what I've done for PAPPL, although if a method were provided to get explicit consent from the user per device I could add support for it.

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

Hello Till,

thank you for your comprehensive and detailed explanation!

It helps (at least me) so much to get a better understanding
how "the whole picture" of future printing will look like.

Could such generic explanations perhaps be added e.g. to
https://openprinting.github.io/upcoming-technologies/
to have a common place where everybody could see
how the future of printing is meant to be?


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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Thu, Feb 25, 2021 at 09:28:47AM +0100, Zdenek Dohnal wrote:
> Solomon, I'm sorry if it is an obvious fact, but I don't know it - would
> you mind me asking why IEEE1284 IDs aren't used so much in drivers?

I can't comment on manufacturer-supplied/supported drivers, but speaking 
of my own experience with Gutenprint we can't use what we don't know 
about.  The tooling that could take advantage of those IDs to 
provide automagic printer setup didn't exist until relatively [1] 
recently, and by then it was a bit too late..

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.

(Of the stuff in Gutenprint, about a quarter of the IEEE1284 IDs, and 
 all of the USB VID/PIDs, were added by myself.)

[1] ie about a decade ago. 
[2] They are in the same family, but the PDL is barely incompatible..

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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 25/02/2021 14:33, Michael Sweet wrote:
> Actually, I don't think you're going to find as many broken IPP-USB printers as you think since all but the first couple HP models  implemented IPP-USB to get AirPrint certification, which means it got tested extensively... :)
>

When I see bug reports on OpenPrinting or Ubuntu on non-working 
IPP-over-USB printers they are usually HP, probably these old printers 
which you mean.

> 
> Up to you, but I would expect some user confirmation before installing any software on my computer...
>

Simply some pop-up like "Found Acme LaserStar 1000+. Install Acme 
Printer Application?" would be enough.

> 
> Why?  The printer application can just be run with the "autoadd" sub-command, no need to link against PAPPL for that.

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

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Solomon Peachy]

[-- 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 --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

Till,

> On Feb 25, 2021, at 10:24 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> 
> On 25/02/2021 14:33, Michael Sweet wrote:
>> Actually, I don't think you're going to find as many broken IPP-USB printers as you think since all but the first couple HP models  implemented IPP-USB to get AirPrint certification, which means it got tested extensively... :)
>> 
> 
> When I see bug reports on OpenPrinting or Ubuntu on non-working IPP-over-USB printers they are usually HP, probably these old printers which you mean.
> 
>> Up to you, but I would expect some user confirmation before installing any software on my computer...
>> 
> 
> Simply some pop-up like "Found Acme LaserStar 1000+. Install Acme Printer Application?" would be enough.

Agreed, potentially with a prompt for the admin password.  Not that I expect malware in the snap store (for example), but we don't want to make it an obvious target.

>> Why?  The printer application can just be run with the "autoadd" sub-command, no need to link against PAPPL for that.
> 
> 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... :/

________________________
Michael Sweet

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

On 25/02/2021 14:43, Michael Sweet wrote:
> That is certainly one approach, and if Canonical is going to provide some general support for finding snaps that support particular hardware (not just printers) then it makes sense.
> 
> That said, the number of printer applications is not likely to be huge (LPrint, hp-printer-app, and ps-printer-app make 3, and potential future HP-LIP and Gutenprint printer applications make 5), so even if you just maintained files with the latest "app-name drivers" output you'd be able to do a good job of mapping printers to printer applications.
> 

First, there will come more Printer Application, one will be the 
Foomatic/Ghostscript/Unmaintained-Legacy one, a SANE legacy one, then 
there is probably also a Braille embosser one, and some for (2-3) for 
other maintained drivers. In addition to that some manufacturers will 
put up some for their specialty printers.

For the maintained ones there can often appear updates with new models.

So maintaining model indices of the Printer Applications externally and 
having them in packages which the distros ship is not a good idea. A 
standard way to get the model list out of a running Printer Application 
is already a good step. As we talked about earlier we can expand the 
"app-name drivers" with options so that you can get a more 
machine-readable list and device IDs.

For keeping up with not installed but available Printer Applications I 
think hardware-signature-based search in the Snap Store would be the 
best solution.

> Remember, Printer Applications are addressing a short term (~10 year?) need to support legacy printers, at which point the primary users will be "experts" that wouldn't use the default printer application/IPP Everywhere support anyways.  New printers almost universally support IPP (the outliers being for "experts").

So one should not need to invest too much time for their perfect 
integration.

Hardware-signature-based search in the Snap Store is not only for 
Printer Applications, and in other hardware categories drivers or 
otherwise hardware-related Snaps could be more common.

A GUI application/GNOME Control Center module which lists available 
Printer Application and provides buttons to their web interfaces, 
auto-add, IPP System Service, ... could be made as general user-oriented 
DNS-SD service lister, where the user also easily finds web interfaces 
for routers, access points, smart home devices, ...

Only the USB auto-setup tool is something more transitional which 
perhaps could go away in 10 years or so.

    Till

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter]

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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Johannes Meixner]

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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

On Fri, Feb 26, 2021 at 11:03:34AM +0100, Johannes Meixner wrote:
> I do not agree that everything involving printing is a complete mess

While printing works better now than it ever has (thanks in part to many 
years of hard work by folks participating here) it remains a continual 
source of headaches, even in tier-one environments (eg Windows) where 
there unfortunately remain economic incentives that work against the 
end-user's interest.

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

This problem is a lot like "self-driving cars", where there's only 
really value when it JustWorks(tm) without any expectation of 
user/operator attention.

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

From a client side, we're already there, though I fear we've recreated 
the problem with PPDs where common end-user printing UIs can't be 
trusted to properly export/display the various options a given printer 
supports.

Meanwhile, as this email thread demonstrates, someone still has to write 
the "driver" for a given printer, and to be honest IPP-Everywhere makes 
this task _much harder_.  Fortunately, this task should only need to be 
done once for a given model, presumably by the manufacturer, so it's 
overall a net improvement... but only if your platform's generic IPP 
client's UI is sufficiently featureful.  Because otherwise you'll end 
right back at the point where custom platform-specific "drivers" are 
necessary, making one wonder if we've actually accomplished anything 
after all of this effort.

(A related recent trend I've seen are printers that only claim to 
 support printing via a manufacturer-supplied smartphone app.  I don't 
 know if they rely on IPP under the hood, but even if they do there's no 
 guarantee it's standards-compliant IPP/Everywhere...)

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

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Solomon Peachy]

[-- Attachment #1: Type: text/plain, Size: 6173 bytes --]

On Thu, Feb 25, 2021 at 11:54:51PM +0100, Till Kamppeter wrote:
> > 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.

Believe me, I'd love to be wrong.  But I don't think I am.  :)

Over the past decade, I've developed a working relationship (of some 
sort) with nearly every dyesub printer manufacturer out there.

Nearly all of them are currently selling "print server" appliances that 
bolt onto their printers; sometimes these are simple headless units 
intended to be used with generic CUPS/Samba/Airprint/Hot Folder clients, 
but they also use that same underlying software platform to provide rich 
UIs tailored to various verticals (eg photo booths, print kiosks, photo 
ID or ID cards).  But most of their printers are sold to folks who build 
competing solutions at various scales.

For their volume markets, adding networking and IPP/Everywhere support 
into the base printer will raise the printer cost and probably won't 
actually get utilized given the need for advanced UIs, putting them at a 
cost disadvantage versus their competition.  For their internal 
"customer" that creates kiosk (etc) solutions, it's much the same, since 
the external appliance will still be needed if only to provide some sort 
of UI, and typically more than one printer will be simultaneously 
connected. Why have three sets of network interfaces and services 
running (and coordinate/manage) when one will do?

Anyway. In all but one case that I'm aware of [1] those appliances (and 
even the rich-UI kiosks) are all built on top of Linux, CUPS, and (far 
more often than not) Gutenprint and my reverse-engineering-derived code.  
The shift to Linux was largely driven by the desire to use cheap ARM 
SBCs allowng them to ditch bulky & expensive PC hardware.

That's where I came in; my relationships are with two groups within 
these printer makers; first their in-house software teams that are 
building these appliances; and secondly, sales teams that have large 
prospective orders contingent on stable operation with random ARM SBCs 
such as the Raspberry Pi, where binary x86 drivers obviously won't do.

I'm not exaggerating to say they've universally had better results 
(faster printing, better feature coverage, and vastly superior support) 
working with me and my reverse-engineered gutenprint(+backend) code than 
with their corporate siblings' in-house driver/SDK teams, often to the 
point of paying me to reverse-engineer their own hardware.

(Not bad for a mini-obsession that is arguably a sign of mental illness...)

This is why I believe that these printer manufacturers aren't ever going 
to create any sort of "downloadable printer application" targeting 
end-users.  Their answer will be (as it already is) "buy our little 
appliance instead". [2]

Now there's definitely a path from the current CUPS+Gutenprint 
implementation of those appliances to a "printer application" model, but 
what will drive that is PAPPL's superior Airprint and future (IPP &| 
printer-specific) features that are impractical (if not impossible) with 
the legacy CUPS paradigm.

Given the historical record, it's all but guaranteed that any such 
printer application won't be written (or even be initiated) in-house, 
instead falling to someone like myself, or others that participate on 
this mailing list. Only once this new application is generally stable 
and provides feature parity with their existing "legacy" solution will 
they even consider switching.  (And it's hard to fault them for that..)

BTW, I don't mean to come across as a bitter naysayer, nor is my intent 
to belittle or denigrate the increcible amount of work you've put into 
this space. As I said earlier, the F/OSS printing experience is the best 
it's ever been, and more than anyone else, we have you and Michael Sweet 
to thank for that.

I like to think I've done my part on that front too; building on your 
work (and Gutenprint!) I've managed to completely break the 
exclusively-proprietary grip on the kiosk/booth verticals and to a 
lesser extent, the Medical/Scientific realm.  The major remaining niche 
on my [s]hit list is the "ID card" space, which encompasses truly 
disgusting levels of vendor lock-in.

So yeah, I'm very much in this to empower the end-user.  :)

But most of my work in this space is self-funded, and as such I haven't 
had the time/bandwidth to put in what's needed to push the 
infrastructure side of things (eg Gutenprint) forward into this new 
world.  I think as an experiment, I'm going to attempt to do an end-run 
around Gutenprint and try to write a "native" PAPPL-based application 
for one of the dyesub printers I have here, and see how that goes...

AAAAnyway.  I've somehow managed to spent two hours writing this, making 
me late signing in to $dayjob.  D'oh..

Cheers,

 - Solomon

[1] Even that singular non-Linux case is now using my reverse-engineered 
    backend code, albeit compiled for Windows, and is deployed to at 
    least 11K locations.

[2] And that's before one considers the implication of product life 
    cycles that routinely exceed a decade; using an external appliance 
    for rapidly-evolving network connectivity makes for much better 
    futureproofing.  I've seen multiple generations of appliance/kiosks 
    come and go while the base printers remain unchanged.
-- 
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 --]

Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

Solomon,

> On Feb 26, 2021, at 7:28 AM, Solomon Peachy <pizza@shaftnet.org> wrote:
> ...
> Meanwhile, as this email thread demonstrates, someone still has to write
> the "driver" for a given printer, and to be honest IPP-Everywhere makes
> this task _much harder_.

For sure, if you start from scratch.  But if you have a ready-made wrapper (i.e. PAPPL) then you can just focus on the driver bits.

> ...
> (A related recent trend I've seen are printers that only claim to
> support printing via a manufacturer-supplied smartphone app.  I don't
> know if they rely on IPP under the hood, but even if they do there's no
> guarantee it's standards-compliant IPP/Everywhere...)

I've seen some of those polaroid-style 3x2 or 3x3 photo printers, and they use a custom Bluetooth protocol.  I haven't seen a regular desktop printer that can only be used via an app in many years... (fortunately)

________________________
Michael Sweet




[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

[Printing-architecture] Future of Printer Setup Tools

[Till Kamppeter]

Hi,

thanks to all of for the fruitful discussion in the thread

    Automatic printer setup with Printer Applications

here on the mailing list.


As a conclusion I would say that we really will not need any more a tool 
which automatically sets up classic (not driverless IPP) USB (or even 
network) printers when connecting them and turning them on.

But we should not let the user get lost without having any reference to 
find and manage printers in the desktop.

We should rather transition the printer setup tools (like 
system-config-printer) to the new architecture.

A typical printer setup tool consists of two parts:

1. The main window: This part shows all already set up CUPS queues and 
you can do changes on them and list and manipulate jobs here.

2. The add-printer wizard: This part pops up if you click the button for 
adding a new print queue. It shows the printers which CUPS discovered 
with its backends and you create a queue by selecting one of the 
printers and assigning driver and queue name to it.

Now to transition to the new architecture, where printers (and scanners) 
are IPP services and not CUPS queues with assigned filter/PPD drivers 
any more, we should transition the two parts as follows:

1. The main window: Here we list all IPP services. Each IPP service 
(defined by a host and a port) is a main entry. Under an IPP service 
there can be 0 (e. g. Printer Application before creating the first 
print queue), 1 (e. g. simple single-function IPP printer), or more (e. 
g. IPP multi-function printers, Printer Application with more than one 
queue) entries for printers/scanners/faxes. Each main entry should get 
two buttons, one to open the web admin interface and one for IPP System 
Service status/configuration. The printer/scanner entries can also have 
buttons, for example to directly link to job list, options panel, ... in 
the web interface, for pause/resume, set as default, ... All info for 
this can be taken from DNS-SD (see avahi-discover output).

2. The add-printer wizard: Here we should have a guide for the user to 
find and set up classic printers. by listing discovered printers, 
listing installed Printer Applications (with polling them whether they 
support the printer), do a Snap Store search with the make/model of the 
printer and the word "printer", ... No auto-association and evaluation 
of drivers to the printer required.

(1) Can also get extended to a general DNS-SD-based network service 
lister (imaging the user can also reach the web interfaces of his router 
and his smart home devices by a click on a button). This is so-to-say 
the user-friendly version of the admin tool avahi-discover.

These tools can be stand-alone, but ideally (1) would be a module of the 
GNOME Control Center and (2) would pop up by a button at the top of (1) 
(like the current "Printers" module in GNOME Control Center).

WDYT?

    Till

Re: [Printing-architecture] Future of Printer Setup Tools

[Johannes Meixner]

Hello,

thank you Till for your comprehensive and explanatory summary.

It helps so much that you act as a kind of "moderator" who
moves discussions forward in a positive and constructive way.

On other mailing lists or forums I see it too often that long
and elaborated discussions fade away in a vague pending state
because there is nobody who acts as a moderator who summarizes
current results so that all know what the current state is.


On 2021-03-02 11:58, Till Kamppeter wrote (excerpts):
> Now to transition to the new architecture, where printers (and
> scanners) are IPP services and not CUPS queues with assigned
> filter/PPD drivers any more, we should transition the two parts as
> follows:
> 
> 1. The main window: Here we list all IPP services. Each IPP service
> (defined by a host and a port) is a main entry. Under an IPP service
> there can be 0 (e. g. Printer Application before creating the first
> print queue), 1 (e. g. simple single-function IPP printer), or more
> (e. g. IPP multi-function printers, Printer Application with more than
> one queue) entries for printers/scanners/faxes. Each main entry should
> get two buttons, one to open the web admin interface and one for IPP
> System Service status/configuration. The printer/scanner entries can
> also have buttons, for example to directly link to job list, options
> panel, ... in the web interface, for pause/resume, set as default, ...
> All info for this can be taken from DNS-SD (see avahi-discover
> output).
> 
> 2. The add-printer wizard: Here we should have a guide for the user to
> find and set up classic printers. by listing discovered printers,
> listing installed Printer Applications (with polling them whether they
> support the printer), do a Snap Store search with the make/model of
> the printer and the word "printer", ... No auto-association and
> evaluation of drivers to the printer required.
> 
> (1) Can also get extended to a general DNS-SD-based network service
> lister (imaging the user can also reach the web interfaces of his
> router and his smart home devices by a click on a button). This is
> so-to-say the user-friendly version of the admin tool avahi-discover.
> 
> These tools can be stand-alone, but ideally (1) would be a module of
> the GNOME Control Center and (2) would pop up by a button at the top
> of (1) (like the current "Printers" module in GNOME Control Center).

my first offhanded thought when reading it was:

Why having that functionality separated in a different tool
and not in the normal printing (or scanning or faxing) dialog?

I describe here only the printing case.

What I have in mind is:

The end-user sits in front of his current application program
and now - all of a sudden - he wants to print from within
his current application program so he opens its print dialog, cf.
https://en.opensuse.org/Concepts_printing#User_expectations
------------------------------------------------------------------
The usability experts Peter Sikking and Jan Mühlig did some
research with real average users. Peter Sikking wrote at
http://www.mmiworks.net/eng/publications/labels/openPrinting.html
...
1st rule of printing: printing does not exist
...
for users there is no worthwhile, productive activity
between the moment they want to see something printed and
the moment it comes out of the printer
...
And guess what: there is no such thing as printing.

It does not exist as a task, as a meaningful activity.
One moment you decide to see it on paper,
the next it rolls out of the printer.
------------------------------------------------------------------

In a proper IPP Everywhere environment all he needs to print
is "magically" already there so he can "just print".

But if not things go wrong for the end-user because he does
not see the needed "buttons" to set up legacy (USB) printers
or to establish access to DNSSD-announced network IPP printers
in his normal print dialog.

So I think printer setup things should be integrated
into the normal print dialog.

If printer setup can be done as normal user all is fine.

If printer setup requires 'root' permissions an appropriate
authentication dialog should pop up. If the user does not know
the root password he knows at least that he would have to contact
an admin to get that task done.

Of course I know that
"there is no such thing as THE normal print dialog"
but this could be another good reason why there should be
one single common print dialog framework/backend
that is used "under the hood" by the desktop toolkits
and (free software) stand-alone applications.

If printer setup functionality could be integrated,
the Common Print Dialog Backends
https://openprinting.github.io/projects/04-print-dialog/
might be better re-named something like
Common Print User Interface Backends (or Framework)


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

Re: [Printing-architecture] Future of Printer Setup Tools

[Till Kamppeter]

On 02/03/2021 13:04, Johannes Meixner wrote:
> 
> Hello,
> 
> thank you Till for your comprehensive and explanatory summary.
> 
> It helps so much that you act as a kind of "moderator" who
> moves discussions forward in a positive and constructive way.
> 
> On other mailing lists or forums I see it too often that long
> and elaborated discussions fade away in a vague pending state
> because there is nobody who acts as a moderator who summarizes
> current results so that all know what the current state is.
>

Thank you very much.

> my first offhanded thought when reading it was:
> 
> Why having that functionality separated in a different tool
> and not in the normal printing (or scanning or faxing) dialog?
> 
> I describe here only the printing case.
> 
> What I have in mind is:
> 
> The end-user sits in front of his current application program
> and now - all of a sudden - he wants to print from within
> his current application program so he opens its print dialog, cf.
> https://en.opensuse.org/Concepts_printing#User_expectations
> ------------------------------------------------------------------
> The usability experts Peter Sikking and Jan Mühlig did some
> research with real average users. Peter Sikking wrote at
> http://www.mmiworks.net/eng/publications/labels/openPrinting.html
> ...
> 1st rule of printing: printing does not exist
> ...
> for users there is no worthwhile, productive activity
> between the moment they want to see something printed and
> the moment it comes out of the printer
> ...
> And guess what: there is no such thing as printing.
> 
> It does not exist as a task, as a meaningful activity.
> One moment you decide to see it on paper,
> the next it rolls out of the printer.
> ------------------------------------------------------------------
> 
> In a proper IPP Everywhere environment all he needs to print
> is "magically" already there so he can "just print".
> 
> But if not things go wrong for the end-user because he does
> not see the needed "buttons" to set up legacy (USB) printers
> or to establish access to DNSSD-announced network IPP printers
> in his normal print dialog.
> 
> So I think printer setup things should be integrated
> into the normal print dialog.
> 
> If printer setup can be done as normal user all is fine.
> 
> If printer setup requires 'root' permissions an appropriate
> authentication dialog should pop up. If the user does not know
> the root password he knows at least that he would have to contact
> an admin to get that task done.
> 
> Of course I know that
> "there is no such thing as THE normal print dialog"
> but this could be another good reason why there should be
> one single common print dialog framework/backend
> that is used "under the hood" by the desktop toolkits
> and (free software) stand-alone applications.
> 
> If printer setup functionality could be integrated,
> the Common Print Dialog Backends
> https://openprinting.github.io/projects/04-print-dialog/
> might be better re-named something like
> Common Print User Interface Backends (or Framework)

Good idea. I think the print dialogs of Mac OS X have this already, some 
button to open the window to add a new printer (part (2) from my 
suggested parts).

The biggest problem here is to get the GUI toolkit projects to implement 
that, or to find contributors to do so.

    Till