[Printing-architecture] Automatic printer setup with Printer Applications

Solomon Peachy pizza at shaftnet.org
Fri Feb 26 14:59:01 UTC 2021

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


 - 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20210226/017bdd04/attachment.sig>

More information about the Printing-architecture mailing list