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

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

Solomon,

> On Aug 2, 2024, at 1:12 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> 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.

Linux at least... macOS has had "CutMedia" (that's the PPD option) support a long time to support roll-fed printers but I know it took a while to get that into the various Linux print dialogs.

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

Multiple document job support is optional in IPP so from iOS you'll either see a single PDF/raster job with multiple pages (one image per page) *or* multiple jobs with a single image per page, depending on whether the printer supports the image file format.  For current iOS clients the original format is typically HEIF and since that format is a patent minefield I'm not aware of any printers that actually support it.  (Certainly CUPS and PAPPL have no plans of supporting it in the near future)

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

There is support for this in PAPPL (in order to minimize inter-job delays) so that bodes well for a future Gutenprint printer application at least... :)

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

So for higher-level formats (PDF in particular) that isn't a problem.  For raster printing you'd be forced to transform the color data on the back side - not ideal/optimal but doable.

We don't currently have a separate attribute for specifying back side resolution/type information, and while that *could* be added I'm guessing it wouldn't be likely to be implemented by IPP clients for the same reasons other low-probability scenarios don't get implemented... :/  But still, for those clients that *do* want to support it we can define them, something like:

- "pwg-raster-document-back-type-supported (1setOf type2 keyword)": Supported color spaces and bit depths for the back side of pages in a PWG raster document.
- "pwg-raster-document-back-resolution-supported (1setOf resolution)": Supported resolutions for the back side of pages in a PWG raster document.

> ...
> Just off the top of my head: Printer resolution, paper size

printer-resolution
media/media-col

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

finishings/finishings-col (which handles the different number and position of cuts)

> common finishing options (eg overcoat type

So for the printers I've written drivers for in the past, the overcoat option has always been on/off (boolean) with the ribbon determining the type (glossy/matte/etc.)

IPP exposes overcoat as a finishing option, and can even specify a type of coating.  Most clients will simply offer a checkbox (coating/no-coating).

> and 
> decurling),

So I've seen printer-implemented "drying" timers to minimize curling/wrinkling/transfer off the printed media, but not an optional finishing step to (I assume) roll out the media to straighten it.  There are two ways we could approach this:

1. Define new finishing enums/keywords for this.
2. Default it based on print quality (best/high == decurl, draft/normal == no-decurl)

I actually think a combination of the two might be ideal, i.e., if #1 isn't specified then do #2, but this is definitely a finishing step that should be selectable.

> sharpening and color correction knobs,

I know there is a strong temptation to put this in drivers, but really these are things best left to the Client software to supply you with a good image and for the driver/printer to reproduce the image as accurately/consistently as possible.

There are rare cases where post processing on the printer/driver side is desirable (I do this in LPrint to improve bar code legibility for example, and color management is another common one) but the guiding principle should be to do only what is necessary to reproduce what you've been given accurately.

> delay time for 
> automatic job combining,

This is probably best as a configuration option in the printer application.  Letting an ordinary user control this from a job could lead to problems.

> quality/speed settings, etc.

print-quality and print-speed are both available.

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

Scaling has long been an issue, even before CUPS.  Part of this is technical, but part is how different users look at scaling (visual-spatial thinkers vs. verbal-sequential) which is why it is so important to have a preview image in the print dialog... :)

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

macOS represents a very small marketshare to them, and quite frankly you can't get away with as much bad programming on macOS as on Windows...

Moreover, Apple has had AirPrint since 2010 which allows manufacturers to support a single thing on their printers for both macOS (small share) and iOS (big share), and Apple has actively pushed them to support AirPrint over writing more drivers during the same period.  And of course once you have done AirPrint it is trivial to support Mopria (Android/ChromeOS/Windows) and IPP Everywhere which are based on the same technology.

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

Yes, the device communication layer is a significant bunch of code, and it might indeed need to be forked to port it to PAPPL.  I hope not, though...

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

I'll think on this - now that I at least know *why* you are doing this I might be able to come up with an alternative that will work.

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

Not exactly, it is just that when you are used to using the hammer yourself it is sometimes hard to think about telling the printer to do something that might use a hammer or might use a different tool to accomplish the same goal.  With IPP you specify print intent, not the low-level detailed instructions.

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

Keep in mind that IPP is also widely used in "light production" environments for printing books (old school), posters, newsletters, magazines, signs, etc. that are all 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.

This has been the case for other printers as well.  And even in the IPP era there are custom client applications for managing these printers and their jobs.  That won't change...

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

So from a (sorry) short-sighted perspective IPP provides no benefit.  But when you look at costs over decades (and believe me there are people that do just that) having a standard protocol for talking to your fleet of devices has HUGE benefits.  Initial time to print *might* be impacted slightly but once you start pushing jobs IPP and network interfaces are faster than the print engine(s).

Being able to monitor what is happening in a heterogeneous environment helps to keep things running smoothly and avoids dependance on a single vendor/supply chain.

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

Some operating systems don't support printer drivers...

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

The core IPP protocol is unchanged from the version published by the IETF in 1998.

We have added new attributes, values, and operations at a DECREASING rate over the last 26 years, and always in a way that preserved backwards compatibility.

The initial IPP printers basically treated IPP as another raw protocol (port 9100, LPD, and IPP), but since 2010 IPP has been a first-class protocol with support for standard file formats.

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

Um, IPP *is* inherently superior to port 9100 and LPD.  Not only do you get encryption and authentication support, you also get status information, job management, etc. that are all MISSING from port 9100 and LPD (as implemented by printers).  "Print and pray" is how port 9100 and LPD are viewed...

________________________
Michael Sweet