Re: Citizen CX-02 incorrect paper dimensions in PPD

Solomon Peachy via Gimp-print-devel <[email protected]> Sat, 3 Aug 2024 22:34:09 -0400
Newsgroups	gmane.linux.printing.gimp-print.devel
Message-ID	<[email protected]>
On Sat, Aug 03, 2024 at 10:46:07AM -0400, Michael Sweet wrote:
> 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... :)

Absolutely.  There are a _lot_ of goodies that are either badly 
shoehorned through the existing CUPS frontend, or simply waiting for the 
day when I can finally bring them into the light.

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

This is another area where having some sort of predefined "profile" 
would be handy. 

A while back I picked up a couple a of surplus ID card printers with an 
eye towards disrupting this (even more proprietary and vendor lockd-in) 
space as well. I had some initial success but the sheer cost of these 
printers (and no meaningful interest/feedback) kept me from pursuing 
this space any further.

***
After I (mostly) broke the propretary SDK-based stranglehold that held 
back these bigger dyesub printers from wider usage. Heck, to this day 
the only reason most (if not all) of this space has _any_ IPP support at 
all is because it came for free on top CUPS+Gutenprint)

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

That was true in the earlier days of this space, but pretty much 
everything under two decades old supports Glossy or Matte selection with 
the same ribbon.

Meanwhile, CX-02 that spawned this thread supports four different 
overcoat types -- None, Glossy, Matte, and Fine Matte. 

As an added bonus it also supports a so-called "partial [fine] matte" 
mode where the user can supply an image that acts as a glossy/matte 
mask, allowing for the creation of a psuedo-watermark effect.  (From the 
printer's perspective, you send this partial/mask over as a second 
set of image data...)

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

....It needs to be generally independent of "quality".  (Or at least 
this is one area where the user's definition of "quality" may disagree 
with the printer's definition.)

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

You're preaching to the choir here, but this is another area where 
things get a little messy, for two reasons:

1) Vendors typically have differentiated themselves with (eg) "the 
Fujifilm look" and this way no matter which of their models was used to 
print an image, or how (ie native SDK, OS/driver(itself written using 
said SDK), whatever), you'll get consistent-looking output and 
not-so-coincidentally locked in to their ecosytem.  Especially when 
_not_ using a formal color managed flow, which is the norm for 
consumer/prosumer spaces.

2) While these printers typically accept 8bpp YMC or RGB raster data, 
translating that over to individual heating elements on the thermal 
print head is a complex process where any given pixel influences the 
others around it in dedicedly non-linear manners.  Most of these 
printers implement these algorithms in realtime using a dedicated ASIC 
or FPGA, but others require this to be pre-computed by the "driver".  
These algorithms usually include a mandatory sharpening pass and other 
knobs that tie into (1).

The worst offender here is (well, was) Mitsubishi. All but two of the 
models they released since 2007 work this way.  Sinfonia requires 
something similar on both of their current 6" models (albeit with no 
user-facing knobs). HiTi is a convoluted mess, with mulitple "color 
modes" with corresponding printer data tables _and_ ICC profiles.

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

This is basically (2) above, but yes, I am otherwise in complete 
agreement.  (FWIW, color management is one of those things that nobody 
ever seems to get right..)

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

A while back I did some significant internal restructuring to make it a 
little more easily adaptable, but there's definitely going to be some 
headaches when the time comes.

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

Well, yeah -- from the _client_ side it's pretty sweet, but from the 
printer/server side, it's the difference between a writing an 
application and having to build/maintain a bespoke container/virtual 
machine -- A huge increase in scope.

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

...But they have to be implemented in a fundamentally different manner.

> So from a (sorry) short-sighted perspective IPP provides no benefit.  

...Welcome to... the sad reality of most corporate decision making?

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

Sure.  Except the folks with the fleets aren't the folks manufacuring 
the printers, and thre are some very pererse incentives in play.

As an example of how insanely myopic these folks can be -- I have been 
engaged by the US or EU branches of printer manufacturers to effectively 
reverse engineer or deubug issues with their own printers, as their 
corporate parents steadfastedly refused to even supply documentation 
*internally* to meet high-profile customer needs. (Usually a variation 
of "we need a solution that can run on a cheap Arm SBC instead of an 
expensive Windows PC")

A project manager at one of these manufacturers later told me that I had 
very nearly been sued -- and he'd only prevented that by making it it 
very loudly known out that this very same company was about to launch a 
new product built on top of what I'd written (ie dysub backend).  This 
turned into a productive (but rocky) multi-year engagement that finally 
ended when their legal team actually did threaten me, this time over a 
feature that had saved them something like half a million dollars.

So... Yeah.  "Short sighted" doesn't begin to describe it.

That final legal nastygram was four years ago, was also the last 
interaction I've had with any printer manufacturer or medium/large scale 
priting solution provider.  And honestly, good riddance.

However. While the manufacturers (and these solution providers) don't 
care, end-users (including myself) that just want to print their photos 
certainly do care.  After all, I only ever started in this space because 
the manufacturers weren't meeting my needs.  And that, along with my 
unhealthy obsession in low-level tinkering, tinker with low-level stuff, 
is why I'm still doing this.

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

...If there are sufficient resources to buffer multiple jobs.  
Hilariously the printers are nearly always capable of that, but the 
driver stacks on top... not so much.

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

To end-users, that's a huge benefit.  To middleware folks... it _could_ 
be.  To printer makers, making it easy to switch to a competitor 
is empatically a *bad* thing.

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

By "IPP" I mean "IPP Everywhere" aka "driverless printing".  That didn't 
land until what, 2010, and took another decade to become truly 
widespread?

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

I'm not comparing IPP to LPD here; if you don't have a network 
interface, _neither_ is an option.

...but you're once again talking about general purpose *end user* 
benefit, not benefit to the manufacturers themselves.  Or even to their 
primary volume customers, who already have their own 
vertically-integrated printing solutions (eg drugstore photo printing 
kioks) that for all I know are already built around IPP.

And from that perspective, the dyesub makers' attitude of "our volume 
customers don't care (and if anything, want us to be _cheaper_) and for 
the little one-off guys that do, just sell a cheesy little add-on print 
server that provides those services" has been GoodEnough(tm) so far.

...If they want or need more than that, they've certainly never 
communicated that with me, much less expressed any interest in helping 
to make it happen.  Suffice it to say, I'm not holding my breath.

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