Re: Citizen CX-02 incorrect paper dimensions in PPD

Solomon Peachy via Gimp-print-devel <[email protected]> Thu, 1 Aug 2024 10:37:34 -0400
Newsgroups	gmane.linux.printing.gimp-print.devel
Message-ID	<[email protected]>
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)

_______________________________________________
Gimp-print-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
signature.asc (application/pgp-signature, 833 B)