Menu
▾
▴
Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD
|
From: Solomon P. <pi...@sh...> - 2024-08-01 14:37:48
|
On Wed, Jul 31, 2024 at 08:01:45PM -0400, Solomon Peachy via Gimp-print-devel wrote:
> (I understand that some, maybe even most use cases don't care about
> this, but improvements to _other_ use cases don't matter if the ones
> you do care about cease to work!)
I've been trying to understand just why this silly and mostly pointless
email exchange has aggivated me so much.
The short version is that I never actually _cared_ about general
purporse printing. My personal use cases consist nearly entirely of
command-line RIP-type stuff. Along those lines, the only
current/classic CUPS functionality I care about is a generic mechanism
to enumerate and specify options.
I got into this space when I ended up with a printer that didn't do what
it said on the box (ie "print images from memory cards"). The
officially supported vendor drivers (under MacOS and Windows) were utter
crap, a trait also shared by what appeared to be pretty much everything
in the market. Heck, this is _still_ largely the case.
So I decided to do something about this so I could use this printer
natively under Linux, in the vein of Top Gear's "How hard can it really
be?" quip. Armed with Gutenprint's support for older models in the
family, I rolled up my sleeves and figured out that (1) the printer used
a different command language than its older siblings, (2) Gutenprint
makes it pretty easy to add new printers into, and (3) this printer
didnt't follow USB Printer class specs so the existing CUPS UPS backend
didn't work.
Two days after I started, I had something that worked well enough for my
immediate need -- printing arbitrary images from Gutenprint's GIMP
plugin.
Since then I basically become the "dye sublimation printer guy". Over
the years what I wrote grew into the all-singing CUPS backend it is
today, supporting something like 150 distinct models from pretty much
every manufacturer. Between the backend and Gutenprint, *every* printer
feature is supported, and thanks to how CUPS exposes options, you didn't
have to resort to proprietary per-manufacturer (and often per-printer)
SDKs to get exactly what you wanted: Consistent looking prints no matter
which printer you were using.
This userbase (notably including myself) don't care about application
print dialogs or cross-OS support; they have an image generated by some
pre-existing pipleine, and they want it to programmically come out a
given printer (which may or may not be directly attached) with a given
set of near-arbitrary options.
This is the _only_ use case I've ever cared about.
But thanks to CUPS, my work was automagically applicable to other use
cases -- Indeed, most of the time, Gutenprint+CUPS worked _better_ than
the manufacturer's official drivers (and/or SDKs) for $other_os.
> Except.. this entire discussion is about how Gutenprint _isn't_ using
> standard sizes, and why can't it just do that instead?
More backstory here -- Let's take the CX-02 again. The overwhelmingly
common use cases for this class of printers are drugstore-type photo
kiosks and photobooths, producing "standard" 4x6inch and a pair of 2x6"
strips respectively.
From the printer's perspective, both are *completely* identical.. except
the latter has one extra cut applied. How do we present this option to
the user? There were two approaches:
* Single PageSize (eg 4x6inch) with an additional, nonstandard/custom
"cut in half" option that (a) many UIs don't display or support, (b)
only works with some sizes, (c) no usable way to present feedback to
the user about what combinations are valid. (fun fact: I actually
implemented code that emitted PPD UIConstraints, and you told me to
not bother because what few clients implemented it were hopelessly
broken)
- OR -
* Do what every printer maker's official Windows (and MacOS) drivers do
and present them as two distinct PageSizes (eg 4x6inch and 2x6*2) for
the user to choose between.
Naturally, I did the latter, and it worked just fine... until AirPrint.
Or more accurately, CUPS moving to an IPP-first model, which combined to:
* "helpfully" deduplicate "media" with the same physical dimensions
even if it had different identifiers.
* Not presenting _any_ options other than the basic "size, color,
orientation, duplexing, copies" needed for typical office printing
tasks.
In other words, it became effectively _impossible_ to simultaneously
support the two overwhelmingly predominant use cases for dyesub
printers. A common workaround was to create multiple printer queues,
each limited to a single print size. This approach scales very poorly
due to exponential numbers of option combinations.
After being pestered about this for some time, I came up with a hack --
Each same-physical-size-but-different-cuts variations got bumped up by
one point. Native CUPS/PPD didn't care, AirPrint+CUPS was happy, and
being full bleed printers anyway, Gutenprint could just drop the extra/
superfluous data.
If there's a better way to do this, I'd love to hear it. But any
approach has to work with existing deployed print clients *today*.
Again, any "solution" that doesn't support required functionality is an
complete non-starter -- Printing Is Revenue. It Has To Work, Now.
> That sounds like a significant functional regression in the UIs.
I don't know when this happened, but what's one more UI/UX setback at
this point?
> Meanwhile. Let's suppose that everything you have said is 100%
> objectively true -- ie that Gutenprint's approach is fundamentally
> incompatible with TheWayThingsAreNowDone(tm), and large parts of it have
> to be rewritten and its overall scope greatly expanded... or what
> exactly?
...For the record I actually agree. But that agreement doesn't
magically make time and resources magically appear.
> Because this really sounds like I'm being "asked" to volunteer myself
> for a solid 2-3 months of unpaid full time work to produce something
> that OtherPeople(tm) want. Then actively maintain, update, and support
> it indefinitely. For free.
>
> ...Screw that.
This is the crux of the matter. Above, I wrote about why I got into
this printing space to begin with, and what my personal use cases
(still) are. All of this IPP (and for the most part, even CUPS) stuff
is at best tangental, yet it is responsible for nearly all of my headaches.
Ironically, it's not the commercial dyesub printing niche that generates
the support burden. Instead, that has historically come from MacOS
users whose consumer-grade printers were abandoned by their makers
(helped along by Apple's near-constant breaking things printer drivers
relied upon).
Then it was heavily supplemented by iPhone/Airprint users. And Android
users. and now, Windows users. All of these are on the long tail ends
of _very_ complex (and nearly entirely proprietary) software stacks that
I have nearly zero influence over or visibility into. Bug reports are
little better than "printing doesn't work properly". Indeed, the only
piece I have _any_ visibility into or meaningful control over is
Gutenprint, a thin sliver crushed at very bottom of that heap.
I got into this printing space to get away from dealing with those
complicated (and proprietary) stacks that only served to get in the way of
what I wanted to do. If anything, it seems like the new status quo is
actually _worse_.
There are of course significant advantages/benefits for a native IPP
frontend to Gutneprint (combined with a great deal of internal
restructuring and new development to take advantage of the new
possibilities). But those benefits nearly entirely accrue to *other
people*. Meanwhile, the *costs* of making all of that happen fall
nearly entirely on... me, if only beacause I didn't have the good sense
to formally walk away sooner.
Not only that, but as best as I can tell, for my use cases, the end
result is actually functionally _worse_ thanks to the harsh reality of
crappy IPP clients and the increase in overall system and runtime
complexity.
In the end, it looks like I will go back to where this started for me;
ie a command-line-based RIP for direct-attached dye-sublimation
printers, and I'll release under a copyleft license in the hope that
other folks find it useful.
Heck, that's effectively what I've been doing all along anyway.
> Gutenprint is 100% Free Software (GPLv2+), provided AS-IS and WITHOUT
> ANY WARRANTY WHATSOEVER. And as the sayings go, "scratch your own
> itches" and "patches welcome".
Faced with high costs and negligible (if not outright negative) personal
benefits, how can the rational conclusion be anything other than "Let
the people who want this functionality do the siginficant work to make
it happen."
(To your immense credit, IPP Everywhere is... everywhere! Seriously,
that's an amazing accomplishment.)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
Dowling Park, FL speachy (libera.chat)
|
