* [Printing-architecture] Automatic printer setup with Printer Applications
@ 2021-02-23 19:27 Till Kamppeter
2021-02-24 7:37 ` Johannes Meixner
` (3 more replies)
0 siblings, 4 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-02-23 19:27 UTC (permalink / raw)
To: Open Printing, Michael Sweet, Jai Luthra, Zdenek Dohnal
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-23 19:27 [Printing-architecture] Automatic printer setup with Printer Applications Till Kamppeter
@ 2021-02-24 7:37 ` Johannes Meixner
2021-02-24 8:03 ` Zdenek Dohnal
` (2 subsequent siblings)
3 siblings, 0 replies; 43+ messages in thread
From: Johannes Meixner @ 2021-02-24 7:37 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-23 19:27 [Printing-architecture] Automatic printer setup with Printer Applications Till Kamppeter
2021-02-24 7:37 ` Johannes Meixner
@ 2021-02-24 8:03 ` Zdenek Dohnal
2021-02-24 11:25 ` Till Kamppeter
2021-02-24 14:17 ` Michael Sweet
2021-03-02 10:58 ` [Printing-architecture] Future of Printer Setup Tools Till Kamppeter
3 siblings, 1 reply; 43+ messages in thread
From: Zdenek Dohnal @ 2021-02-24 8:03 UTC (permalink / raw)
To: Till Kamppeter, Open Printing, Michael Sweet, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 8:03 ` Zdenek Dohnal
@ 2021-02-24 11:25 ` Till Kamppeter
2021-02-24 12:01 ` Johannes Meixner
2021-02-24 12:48 ` Solomon Peachy
0 siblings, 2 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 11:25 UTC (permalink / raw)
To: Zdenek Dohnal, Open Printing, Michael Sweet, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 11:25 ` Till Kamppeter
@ 2021-02-24 12:01 ` Johannes Meixner
2021-02-24 13:51 ` Till Kamppeter
2021-02-24 12:48 ` Solomon Peachy
1 sibling, 1 reply; 43+ messages in thread
From: Johannes Meixner @ 2021-02-24 12:01 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 11:25 ` Till Kamppeter
2021-02-24 12:01 ` Johannes Meixner
@ 2021-02-24 12:48 ` Solomon Peachy
2021-02-24 14:01 ` Johannes Meixner
` (2 more replies)
1 sibling, 3 replies; 43+ messages in thread
From: Solomon Peachy @ 2021-02-24 12:48 UTC (permalink / raw)
To: Till Kamppeter; +Cc: Open Printing, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 12:01 ` Johannes Meixner
@ 2021-02-24 13:51 ` Till Kamppeter
2021-02-25 10:30 ` Johannes Meixner
0 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 13:51 UTC (permalink / raw)
To: Johannes Meixner, printing-architecture, Zdenek Dohnal,
Michael Sweet, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 12:48 ` Solomon Peachy
@ 2021-02-24 14:01 ` Johannes Meixner
2021-02-24 17:23 ` Till Kamppeter
2021-02-24 14:17 ` Till Kamppeter
2021-02-25 8:28 ` Zdenek Dohnal
2 siblings, 1 reply; 43+ messages in thread
From: Johannes Meixner @ 2021-02-24 14:01 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-23 19:27 [Printing-architecture] Automatic printer setup with Printer Applications Till Kamppeter
2021-02-24 7:37 ` Johannes Meixner
2021-02-24 8:03 ` Zdenek Dohnal
@ 2021-02-24 14:17 ` Michael Sweet
2021-02-24 14:46 ` Johannes Meixner
` (2 more replies)
2021-03-02 10:58 ` [Printing-architecture] Future of Printer Setup Tools Till Kamppeter
3 siblings, 3 replies; 43+ messages in thread
From: Michael Sweet @ 2021-02-24 14:17 UTC (permalink / raw)
To: Till Kamppeter; +Cc: printing-architecture, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 12:48 ` Solomon Peachy
2021-02-24 14:01 ` Johannes Meixner
@ 2021-02-24 14:17 ` Till Kamppeter
2021-02-25 15:28 ` Solomon Peachy
2021-02-25 8:28 ` Zdenek Dohnal
2 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 14:17 UTC (permalink / raw)
To: Solomon Peachy; +Cc: Open Printing, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 14:17 ` Michael Sweet
@ 2021-02-24 14:46 ` Johannes Meixner
2021-02-24 18:47 ` Till Kamppeter
2021-02-24 17:40 ` Till Kamppeter
2021-02-25 8:52 ` Zdenek Dohnal
2 siblings, 1 reply; 43+ messages in thread
From: Johannes Meixner @ 2021-02-24 14:46 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 14:01 ` Johannes Meixner
@ 2021-02-24 17:23 ` Till Kamppeter
2021-02-26 9:17 ` Johannes Meixner
0 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 17:23 UTC (permalink / raw)
To: Johannes Meixner, printing-architecture, Michael Sweet,
Jai Luthra, Zdenek Dohnal
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 14:17 ` Michael Sweet
2021-02-24 14:46 ` Johannes Meixner
@ 2021-02-24 17:40 ` Till Kamppeter
2021-02-24 17:48 ` Michael Sweet
2021-02-25 8:52 ` Zdenek Dohnal
2 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 17:40 UTC (permalink / raw)
To: Michael Sweet; +Cc: printing-architecture, Jai Luthra
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.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 17:40 ` Till Kamppeter
@ 2021-02-24 17:48 ` Michael Sweet
2021-02-24 19:21 ` Till Kamppeter
0 siblings, 1 reply; 43+ messages in thread
From: Michael Sweet @ 2021-02-24 17:48 UTC (permalink / raw)
To: Till Kamppeter; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 14:46 ` Johannes Meixner
@ 2021-02-24 18:47 ` Till Kamppeter
0 siblings, 0 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 18:47 UTC (permalink / raw)
To: Johannes Meixner, printing-architecture, Michael Sweet,
Jai Luthra, Zdenek Dohnal
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 17:48 ` Michael Sweet
@ 2021-02-24 19:21 ` Till Kamppeter
2021-02-24 20:01 ` Michael Sweet
0 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 19:21 UTC (permalink / raw)
To: Michael Sweet; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 19:21 ` Till Kamppeter
@ 2021-02-24 20:01 ` Michael Sweet
2021-02-24 20:15 ` Till Kamppeter
0 siblings, 1 reply; 43+ messages in thread
From: Michael Sweet @ 2021-02-24 20:01 UTC (permalink / raw)
To: Till Kamppeter; +Cc: printing-architecture, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 20:01 ` Michael Sweet
@ 2021-02-24 20:15 ` Till Kamppeter
0 siblings, 0 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-02-24 20:15 UTC (permalink / raw)
To: Michael Sweet; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 12:48 ` Solomon Peachy
2021-02-24 14:01 ` Johannes Meixner
2021-02-24 14:17 ` Till Kamppeter
@ 2021-02-25 8:28 ` Zdenek Dohnal
2021-02-25 14:54 ` Solomon Peachy
2 siblings, 1 reply; 43+ messages in thread
From: Zdenek Dohnal @ 2021-02-25 8:28 UTC (permalink / raw)
To: Solomon Peachy, Till Kamppeter; +Cc: Open Printing, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 14:17 ` Michael Sweet
2021-02-24 14:46 ` Johannes Meixner
2021-02-24 17:40 ` Till Kamppeter
@ 2021-02-25 8:52 ` Zdenek Dohnal
2021-02-25 9:24 ` Till Kamppeter
2021-02-25 13:33 ` Michael Sweet
2 siblings, 2 replies; 43+ messages in thread
From: Zdenek Dohnal @ 2021-02-25 8:52 UTC (permalink / raw)
To: Michael Sweet, Till Kamppeter; +Cc: printing-architecture, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 8:52 ` Zdenek Dohnal
@ 2021-02-25 9:24 ` Till Kamppeter
2021-02-25 9:54 ` Zdenek Dohnal
2021-02-25 13:43 ` Michael Sweet
2021-02-25 13:33 ` Michael Sweet
1 sibling, 2 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-02-25 9:24 UTC (permalink / raw)
To: Zdenek Dohnal, Michael Sweet; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 9:24 ` Till Kamppeter
@ 2021-02-25 9:54 ` Zdenek Dohnal
2021-02-25 13:43 ` Michael Sweet
1 sibling, 0 replies; 43+ messages in thread
From: Zdenek Dohnal @ 2021-02-25 9:54 UTC (permalink / raw)
To: Till Kamppeter, Michael Sweet; +Cc: printing-architecture, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 13:51 ` Till Kamppeter
@ 2021-02-25 10:30 ` Johannes Meixner
2021-02-25 13:37 ` Till Kamppeter
2021-02-25 13:53 ` Michael Sweet
0 siblings, 2 replies; 43+ messages in thread
From: Johannes Meixner @ 2021-02-25 10:30 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 8:52 ` Zdenek Dohnal
2021-02-25 9:24 ` Till Kamppeter
@ 2021-02-25 13:33 ` Michael Sweet
2021-02-25 15:24 ` Till Kamppeter
1 sibling, 1 reply; 43+ messages in thread
From: Michael Sweet @ 2021-02-25 13:33 UTC (permalink / raw)
To: Zdenek Dohnal; +Cc: printing-architecture, Jai Luthra, Till Kamppeter
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 10:30 ` Johannes Meixner
@ 2021-02-25 13:37 ` Till Kamppeter
2021-02-25 14:00 ` Johannes Meixner
2021-02-25 13:53 ` Michael Sweet
1 sibling, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-25 13:37 UTC (permalink / raw)
To: Johannes Meixner, printing-architecture, Michael Sweet,
Jai Luthra, Zdenek Dohnal
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 9:24 ` Till Kamppeter
2021-02-25 9:54 ` Zdenek Dohnal
@ 2021-02-25 13:43 ` Michael Sweet
2021-02-25 19:39 ` Till Kamppeter
1 sibling, 1 reply; 43+ messages in thread
From: Michael Sweet @ 2021-02-25 13:43 UTC (permalink / raw)
To: Till Kamppeter; +Cc: printing-architecture, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 10:30 ` Johannes Meixner
2021-02-25 13:37 ` Till Kamppeter
@ 2021-02-25 13:53 ` Michael Sweet
1 sibling, 0 replies; 43+ messages in thread
From: Michael Sweet @ 2021-02-25 13:53 UTC (permalink / raw)
To: Johannes Meixner; +Cc: printing-architecture
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 13:37 ` Till Kamppeter
@ 2021-02-25 14:00 ` Johannes Meixner
0 siblings, 0 replies; 43+ messages in thread
From: Johannes Meixner @ 2021-02-25 14:00 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 8:28 ` Zdenek Dohnal
@ 2021-02-25 14:54 ` Solomon Peachy
2021-02-26 10:03 ` Johannes Meixner
0 siblings, 1 reply; 43+ messages in thread
From: Solomon Peachy @ 2021-02-25 14:54 UTC (permalink / raw)
To: Zdenek Dohnal; +Cc: Open Printing, Jai Luthra, Till Kamppeter
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 13:33 ` Michael Sweet
@ 2021-02-25 15:24 ` Till Kamppeter
2021-02-25 15:30 ` Michael Sweet
0 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-25 15:24 UTC (permalink / raw)
To: Michael Sweet, Zdenek Dohnal; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 14:17 ` Till Kamppeter
@ 2021-02-25 15:28 ` Solomon Peachy
2021-02-25 22:54 ` Till Kamppeter
0 siblings, 1 reply; 43+ messages in thread
From: Solomon Peachy @ 2021-02-25 15:28 UTC (permalink / raw)
To: Till Kamppeter; +Cc: Open Printing, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 15:24 ` Till Kamppeter
@ 2021-02-25 15:30 ` Michael Sweet
2021-02-25 21:51 ` Till Kamppeter
0 siblings, 1 reply; 43+ messages in thread
From: Michael Sweet @ 2021-02-25 15:30 UTC (permalink / raw)
To: Till Kamppeter; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 13:43 ` Michael Sweet
@ 2021-02-25 19:39 ` Till Kamppeter
0 siblings, 0 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-02-25 19:39 UTC (permalink / raw)
To: Michael Sweet; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 15:30 ` Michael Sweet
@ 2021-02-25 21:51 ` Till Kamppeter
0 siblings, 0 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-02-25 21:51 UTC (permalink / raw)
To: Michael Sweet; +Cc: printing-architecture, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 15:28 ` Solomon Peachy
@ 2021-02-25 22:54 ` Till Kamppeter
2021-02-26 14:59 ` Solomon Peachy
0 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-02-25 22:54 UTC (permalink / raw)
To: Solomon Peachy; +Cc: Open Printing, Jai Luthra
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-24 17:23 ` Till Kamppeter
@ 2021-02-26 9:17 ` Johannes Meixner
0 siblings, 0 replies; 43+ messages in thread
From: Johannes Meixner @ 2021-02-26 9:17 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 14:54 ` Solomon Peachy
@ 2021-02-26 10:03 ` Johannes Meixner
2021-02-26 12:28 ` Solomon Peachy
0 siblings, 1 reply; 43+ messages in thread
From: Johannes Meixner @ 2021-02-26 10:03 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-26 10:03 ` Johannes Meixner
@ 2021-02-26 12:28 ` Solomon Peachy
2021-02-27 21:07 ` Michael Sweet
0 siblings, 1 reply; 43+ messages in thread
From: Solomon Peachy @ 2021-02-26 12:28 UTC (permalink / raw)
To: Johannes Meixner; +Cc: printing-architecture
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-25 22:54 ` Till Kamppeter
@ 2021-02-26 14:59 ` Solomon Peachy
0 siblings, 0 replies; 43+ messages in thread
From: Solomon Peachy @ 2021-02-26 14:59 UTC (permalink / raw)
To: Till Kamppeter; +Cc: Open Printing, Jai Luthra
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Automatic printer setup with Printer Applications
2021-02-26 12:28 ` Solomon Peachy
@ 2021-02-27 21:07 ` Michael Sweet
0 siblings, 0 replies; 43+ messages in thread
From: Michael Sweet @ 2021-02-27 21:07 UTC (permalink / raw)
To: Solomon Peachy; +Cc: printing-architecture
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* [Printing-architecture] Future of Printer Setup Tools
2021-02-23 19:27 [Printing-architecture] Automatic printer setup with Printer Applications Till Kamppeter
` (2 preceding siblings ...)
2021-02-24 14:17 ` Michael Sweet
@ 2021-03-02 10:58 ` Till Kamppeter
2021-03-02 12:04 ` Johannes Meixner
3 siblings, 1 reply; 43+ messages in thread
From: Till Kamppeter @ 2021-03-02 10:58 UTC (permalink / raw)
To: Open Printing, Michael Sweet, Jai Luthra, Zdenek Dohnal
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Future of Printer Setup Tools
2021-03-02 10:58 ` [Printing-architecture] Future of Printer Setup Tools Till Kamppeter
@ 2021-03-02 12:04 ` Johannes Meixner
2021-03-02 22:52 ` Till Kamppeter
0 siblings, 1 reply; 43+ messages in thread
From: Johannes Meixner @ 2021-03-02 12:04 UTC (permalink / raw)
To: printing-architecture
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
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Printing-architecture] Future of Printer Setup Tools
2021-03-02 12:04 ` Johannes Meixner
@ 2021-03-02 22:52 ` Till Kamppeter
0 siblings, 0 replies; 43+ messages in thread
From: Till Kamppeter @ 2021-03-02 22:52 UTC (permalink / raw)
To: Johannes Meixner, printing-architecture, Jai Luthra,
Zdenek Dohnal, Michael Sweet
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
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2021-03-02 22:52 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-23 19:27 [Printing-architecture] Automatic printer setup with Printer Applications Till Kamppeter
2021-02-24 7:37 ` Johannes Meixner
2021-02-24 8:03 ` Zdenek Dohnal
2021-02-24 11:25 ` Till Kamppeter
2021-02-24 12:01 ` Johannes Meixner
2021-02-24 13:51 ` Till Kamppeter
2021-02-25 10:30 ` Johannes Meixner
2021-02-25 13:37 ` Till Kamppeter
2021-02-25 14:00 ` Johannes Meixner
2021-02-25 13:53 ` Michael Sweet
2021-02-24 12:48 ` Solomon Peachy
2021-02-24 14:01 ` Johannes Meixner
2021-02-24 17:23 ` Till Kamppeter
2021-02-26 9:17 ` Johannes Meixner
2021-02-24 14:17 ` Till Kamppeter
2021-02-25 15:28 ` Solomon Peachy
2021-02-25 22:54 ` Till Kamppeter
2021-02-26 14:59 ` Solomon Peachy
2021-02-25 8:28 ` Zdenek Dohnal
2021-02-25 14:54 ` Solomon Peachy
2021-02-26 10:03 ` Johannes Meixner
2021-02-26 12:28 ` Solomon Peachy
2021-02-27 21:07 ` Michael Sweet
2021-02-24 14:17 ` Michael Sweet
2021-02-24 14:46 ` Johannes Meixner
2021-02-24 18:47 ` Till Kamppeter
2021-02-24 17:40 ` Till Kamppeter
2021-02-24 17:48 ` Michael Sweet
2021-02-24 19:21 ` Till Kamppeter
2021-02-24 20:01 ` Michael Sweet
2021-02-24 20:15 ` Till Kamppeter
2021-02-25 8:52 ` Zdenek Dohnal
2021-02-25 9:24 ` Till Kamppeter
2021-02-25 9:54 ` Zdenek Dohnal
2021-02-25 13:43 ` Michael Sweet
2021-02-25 19:39 ` Till Kamppeter
2021-02-25 13:33 ` Michael Sweet
2021-02-25 15:24 ` Till Kamppeter
2021-02-25 15:30 ` Michael Sweet
2021-02-25 21:51 ` Till Kamppeter
2021-03-02 10:58 ` [Printing-architecture] Future of Printer Setup Tools Till Kamppeter
2021-03-02 12:04 ` Johannes Meixner
2021-03-02 22:52 ` Till Kamppeter
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.