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