Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD

[Solomon P. <pi...@sh...>]

On Thu, Aug 01, 2024 at 12:36:01PM -0400, Michael Sweet wrote:
> Actually, if it was a "cut media" option that is fairly well supported 
> these days and maps well to IPP...

Except... contemporary clients at the time didn't present the option.

> Third option: offer a 2x6 page size and merge pages in a job to the 4x6 media.

I've actually tried to go down variations of this path multiple times, 
but kept running into the fundamental problem that 98% of the time for 
photo printing, each image/page is submitted as an independent job. (ie 
unless you create a multi-page PDF and submit that) Which, the last time 
I checked, neither iOS or Android's printing functionality (&| their 
photo apps' use of said functionality) work that way.

So there's no way to do job combining (for the typical users) without 
creating some sort of daemon that sits around and waits after one job is 
"finished" for something else to show up before asynchronously sendng 
something to the printer.

Incidently, that's one of the things I was most excited about a Printer 
Application; intra-job state effectively comes along for free. There's 
actually a _lot_ of automagic page/job combining logic sitting unused in 
the backend right now.  Suffice it to say I'd _really_ like to have this 
capability...

Meanwhile, there's another wrinkle for things like ID cards printers, 
where each side of the card may require completely different parameters 
to the point of full CMYK on the front but only K the back (and K can be 
greyscale or 1bpp resin. oh, and different per side.  It all depends on 
the ribbon being used.  Which also may or may not have a lamination 
layer on either side)..  I don't know if that level ove 
each-page-has-different-properties is even expressible under IPP.

> That's not CUPS, that is GNOME, KDE, etc.

And more importantly, iOS, Android...

(Actually, Gnome, KDE, etc worked just fine.  Pretty sure they still do, 
 if you use local CUPS queues instead of the auto-discovered IPP stuff)

> Which functionality exists for these printers beyond the size of the 
> output and the number of copies? (orientation, scaling, etc. are all 
> handled by the client)

Just off the top of my head: Printer resolution, paper size and the 
number/position of cuts (which are nearly always a fixed set of 
enumerated combinations as opposed to being a finishing option on 
any/all print sizes) common finishing options (eg overcoat type and 
decurling), sharpening and color correction knobs, delay time for 
automatic job combining, quality/speed settings, etc.

Incidently, For whatever reason, scaling, etc *still don't* seamlessly 
work, based on the complaints I still get about white margins showing up 
on the sides of prints.  (that's slowly improved thanks to Till's work 
with cups-filters, but telling non-technically-inclined people they have 
to effectively recompile their environment's entire printing stack (or 
"use a different application to print your pictures") doesn't go over 
well...)

> It isn't reasonable to assume that a driver written for MacOS X 10.2 
> on PowerPC and *never* updated would continue to work on macOS 14 on 
> Intel/ARM some 22 years later, even if the printer it supports still 
> works.  

Oh I agree, except I'm not talking about a gap like that.  Instead it's 
tier-ones like Canon not providing drivers for anything more than a 
single MacOS release, outright refusing even to consider relase+1.

Incidently, I have one printer in my fleet that was introduced in *2003* 
and is _still_ actively supported (new media, firmware, and current 
Windows drivers) by its manufacturer.  But that's an outlier; typically 
these things have a product lifecycle a bit over a decade.

> But don't try to blame Apple for printer vendors failing to support 
> their products

I'm sorry, but Apple absolutely carries at least part of the blame here, 
and I say that as someeone who has been involved with trying to provide 
MacOS printer drivers.  Nearly *every* MacOS release for the better part 
of a decade broke something Gutenprint depended on, becoming a release 
blocker.  (That's why Gutenprint hasn't generated a new formal release 
since *2019*.  It would be one thing if we derived actual *revenue* from 
MacOS and used that to pay folks to do this work, but that's not how 
this works)

> printer vendors have historically used terrible software engineering 
> practices (no version control/code repositories, no way to re-build 
> their software, etc.) 

I'm all too familiar with this, unfortunately.

> and *that* combined with a lack of incentive to support products 
> beyond their release is the reason for broken drivers, NOT changes 
> made by Apple.

Not *solely*, perhaps.  But when those same printer manufacturers 
release drivers for newer versions of Windows, but not MacOS.. as the 
saying goes, where there's smoke, there's probably fire.

And when you consider these printers require use of 
printer/model-specific media (ie ribbon+paper) and that's where the real 
money lies.  The easier it is for folks to make prints, the more they 
will print, the more media you will sell, and the more money you make.  

Of course, that doesn't mean the printer manufacturer won't shooot 
themselves in the foot. To beat up on Canon again, their latest SELPHY 
CP printers use the same media kits as the first model they ever 
produced over two decades ago.  There have been only two hardware 
generations (each with its own PDL and communication) in that whole 
time, yet for some reason they insist on each individual model requiring 
a unique driver... which they almost never update or support after the 
initial release.

> The biggest "breakage" events were when PPC emulation was removed 
> (10.6) and when code signing became required (10.14).

That 10.6 period largely coresponds with my increasing involvedment with 
Gutenprint, and 10.13 or 10.14 was when our support effectively ended.

> I'm not at Apple anymore but they don't seem to be changing anything 
> meaningful in the printing stack on macOS...

FWIW it usually wasn't the "printing stack" that broke us, but something 
_else_ in the OS.

> One of my goals has been to support/develop/mentor a Gutenprint 
> printer application based on PAPPL. That would give you your 
> command-line RIP *and* instant support for all of the IPP-based 
> clients.

Till and I are on our third consecutive GSoC attempt to make this 
happen. But there's a wide gap between "willing to help/support/mentor" 
and "doing it myself."  But more on that in a bit.

> *I* am *not* trying to put this all on your shoulders, and I also 
> totally understand that supporting Gutenprint (or any printing 
> software) is a mostly thankless task... 

To put it mildly.

As you can probably tell from these emails, I only ever had an interest 
in the low-level printer interaction sort of stuff. Other than reworking 
my talk-to-the-printer code to be usable as a CUPS backend, Everything 
else higher in the well-layered stack (largely including the rest of 
Gutenprint) was SomeoneElse'sProblem(tm).  And that worked fine for a 
long time, becuse there were OtherPeople maintaining those parts of the 
overall system.

Except those OtherPeople have all left or otherwise abandoned the rest 
of the stack -- heck, the entire printing _system_ -- I simply don't 
have the personal bandwidth to tackle everything. Or much of anything.

To quote Ben Horowitz [1]:

  "There are no silver bullets for this, only lead bullets."  

Every path forward requires competent developers to (a) carefully write 
a decent pile of very domain-specific code, and (b) support/maintain it 
going forward.

And unless someone wants to throw a pile of money my way [2], that 
person wont't be me.

..And while (a) might represent 90% of the overall effort, (b) 
represents the second 90%.  (as demonstrated by the initial context of 
this email)

> But I *do* want to have a discussion to understand the issues 
> surrounding supporting certain printers so that a) I can advocate for 
> those kinds of printers in the Printer Working Group, b) I can make 
> sure that PAPPL supports what is needed for those printers, and c) I 
> can eventually help make Gutenprint available as a printer 
> application.

I'll tackle these in reverse order.

(c) PAPPL makes a hell of a difference, of course, and for minimal 
"Print office documents on USB-print-class-compliant PCL/inkjet 
printers" it should't be _that_ much effort. (Basically everything but 
the dyesubs) This is the scope of the recurring GSoC efforts.  Assuming 
that succeeds this third time, here are two major followup prongs:

 * Figure out how to make available the approximately one gajillion 
   knobs for tuning the printer output (especially for Epson inkjets) 
   You've already said they can't be directly exported due to IPP client 
   limitations, so maybe this can be done using some sort of 
   configurable profile mechanism.  Which has to be created, along with 
   suitable UI, etc etc.

 * Figure out how to adapt/integrate the gutenprint USB dyesub backend's 
   functionality in a way that doesn't result in a hard fork and 
   wholesale duplication of code. Aside from basic communications, this 
   includes job combining and splitting, various processing functions 
   that couldn't be done within gutenprint (due to layering or licensing 
   considerations), media/status reporting, configuring nonvolatile 
   printer options, and even firmware updates for one printer family.

Anything beyond the minimal GSoC scope is almost guaranteed to require 
creating new libgutenprint (and libgutenprintui) APIs, likely 
significant frontend work within PAPPL's UI, plus heavy modifications of 
the dyesub code within core gutenprint and its external (>33KLoC!) 
backend (which in turn also likely requires mucking with PAPPL)

...All this before anything _new_ is added beyond the current feature set.

(Which reminds me -- I _still don't have an answer on what we should be 
 doing with respect to the original complaint that led to this thread; 
 ie "the printer accurately reports that it uses custom sizes, and 
 lying/pretending otherwise will require fundamental alterations to how 
 it works with sizes internally, plus rescaling/padding/cropping what 
 the user supplied.")

(b) I touched on sone of this above, but ultimately the only way we're 
going to know what else PAPPL needs is to (heh) FAFO.  This is what I 
was referring to with my "lead bullets" remarks -- it's going to take a 
lot of work, and I'd hoped the GSoC stuff would start that rolling.

(a) When I was first introduced to Java, and someone described it as 
"making hard things easy and easy things hard."  That seems to apply to 
IPP as well.  

FWIW, I don't speak for anyone other than myself (based in part on 
conversations and general industry exposure over the years)

First, these aren't "printers" so much as "industrial equipment", 
deployed as part of some larger system that produces something that is 
will be sold for money.

As such, this class of printers is only rarely "shared" over a network.  
Printing is nearly exclusively using direct connections from a custom 
application running on the local system. More often than not, the 
OS-level printer stack is bypassed competely.

From that perspective, IPP is completely superfluous.  Both because the 
functionality it offers is unnecessary (least of which being that all 
printing is local) and because even in a best-case scenario, it adds a 
_lot_ of overhead that just slows things down.  (In this general market, 
time-to-print and prints-per-hour (with each print typically being a 
separate self-contained job!) numbers can matter even more than the 
incremental price-per-print)

For situations when these printers need to be made available to generic 
applications, they provide standard OS drivers.  And if the printer 
needs to be exported over the network, the OS can handle that.  Why 
reimpement the wheel and drive product complexity & cost upwards when it 
won't be of use to the majority of the suer base?

Meanwhile, these are printers that have production lifecycles that 
routinely exceed a decade, and are supported well beyond that.  IPP has 
iterated so rapidly (and the reality of having a network-facing device) 
is such that it makes sense for an industrial printer maker to 
completely decouple this functionality.

Now the makers know that there are other markets for these printers, and 
those markets may require driver-less network printing support. This was 
traditionally handled using a "hot folder" sort of arrangement (ie you 
upload files to a network share) running on some sort of server (these 
days typically Linux+SAMBA) which prints them out based on 
pre-configured settings) but more recently, AirPrint etc has allowed 
them to support mobile-centric clients (usually thanks to CUPS).

So while they care about IPP, it is not because of any inherent 
superiority of IPP, but because that's what it takes to support 
AirPrint.  Even with AirPrint+IPP, everyone seems to heavily push their 
own dedicated apps that give the user a richer experience (more control 
knobs, better status reporting, and I'm sure all sorts of data 
collection and tie-ins with various cloudy services).  I have no idea if 
these apps also use IPP under the hood (I know Canon's doesn't!), but 
years ago I was told that the first version the app to one 
manufacturer's print server was motivated by standard iOS printing not 
supporting/exposing some critical feature. (In hindsight it was probably 
the ability to configure the printer to generate 2x6" strips instead of 
a single 4x6")

ANYWay. To loop back to the beginning, IPP lets folks do all sorts of 
complicated things relatively easily, but it makes "simple" things a lot 
harder because the simple things have to be handled the same way as the 
complicated things. So when all you care about are those "simple" things 
(because you already have elaborate business-specific 
software/infrastructure to take care of the complicated stuff) it 
becomes an easy "all cost, but no benefit" decision to make.

Where they do care about IPP in of itself, it is because they are 
selling additional products (or services) that build on top of the 
actual printers.  The stuff on top iterates rapidly (one maker I'm 
familar with has gone through at least four major hardware revisions and 
even more software revisions of their "print server" sice 2015) but the 
actual printers do not.  (their _newest_ model was releasd in 2020 and 
the oldest still-in-production model was introduced in 2011, only 
because they had to cease prouction of a model introduced in 2007 due to 
COVID supply chain issues, and it remains in active support to this day)

 [1] https://a16z.com/lead-bullets/
 [2] ie enough for me to quit my never-had-anything-to-do-with-printing
     $dayjob.  Which I am _really_ happy at, btw.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)