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

[Michael S. <ms...@ms...>]

Solomon,

> On Aug 1, 2024, at 10:37 AM, Solomon Peachy <pi...@sh...> wrote:
> ...
> 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.

That's where *I* started with the Gimp-Print plugin all those years ago...

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

Actually, if it was a "cut media" option that is fairly well supported these days and maps well to IPP...

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

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

> Naturally, I did the latter, and it worked just fine... until AirPrint.  

The changes you speak of happened for CUPS 1.4, which was released in 2009 (16 years ago...)

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

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

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

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)

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

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.  Obviously if you still have the same hardware/OS, it will continue to work.  But don't try to blame Apple for printer vendors failing to support their products - printer vendors have historically used terrible software engineering practices (no version control/code repositories, no way to re-build their software, etc.) 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.

During my tenure at Apple we bent over backwards to preserve driver compatibility. Sometimes that meant shipping old shared libraries that drivers were using (but shouldn't have been), or including code translation support (PPC to Intel, Intel to ARM), or leaving holes in the sandbox/security profiles for specific drivers until they could be updated.  The biggest "breakage" events were when PPC emulation was removed (10.6) and when code signing became required (10.14).  I'm not at Apple anymore but they don't seem to be changing anything meaningful in the printing stack on macOS...

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

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.

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

________________________
Michael Sweet