Re: Citizen CX-02 incorrect paper dimensions in PPD

Solomon Peachy via Gimp-print-devel <[email protected]> Wed, 31 Jul 2024 20:01:45 -0400
Newsgroups	gmane.linux.printing.gimp-print.devel
Message-ID	<[email protected]>
On Wed, Jul 31, 2024 at 03:00:03PM -0400, Michael Sweet wrote:
> Perhaps to "fast track" this discussion, does this printer just use a 
> roll of media and cut it to the desired size?

Yes, albeit with various limitations on the allowed sizes.

(And then there are models that use discrete sheets.  Nominally they are 
 usually a "standard" size (PC, L, etc) but in reality pretty much 
 _every_ printer family differs slightly on both the physical media size 
 and the overbleed.)

> If so, the best thing to do here is report min/max roll (custom) 
> sizes, with a selection of "standard" photo sizes (as currently) that 
> are imposed on the roll with pixel duplication at the edges to avoid 
> bleed issues.  

...I'm not sure how this is supposed to work any better than what we 
have now?  After all, it's all "custom" either way.  

Meanwhile, pixel duplication for overbleed inside gutenprint is 
insufficient, as that will all but guarantee that there will be a 
visible artifact on at least one edge of the print.  

To take the CX-02 for example, in a perfect ideal world the imageable 
area is 1.5mm-2mm larger than the physical paper size. Cutting the 
imageable area down to a perfect 4x6" @300dpi means we are, at best, 
0.1mm shy of filling the paper competely on all four sides, and at worst 
(but still within spec) we could be over 2mm off on one or two sides.

> From the outside, the printer supports printing on a roll and/or 
> printing to specific "standard" sizes.  Gutenprint then handles any 
> scaling/imposition to the printer's internal buffer/roll format from 
> the raster data it gets from the print client/filters.

It is a hard requirement that there *must* be a way to say "just print 
this image as supplied, with absolutely minimal processing" -- and part 
of that is "tell me what the ideal image dimensions need to be so I can 
supply an optimized pre-scaled/sharpened/etc image."

Lying about the required image size and forcing an internal rescaling is 
completely unacceptable.

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

> Reporting non-standard sizes with standard names doesn't work on any 
> OS

Except.. this entire discussion is about how Gutenprint _isn't_ using 
standard sizes, and why can't it just do that instead?

> - macOS, for example, will report the odd sizes in the UI and any 
> CUPS-based client on Linux will likewise show odd dimensional names 
> and not the "localized" size names from the PPD file. 

That sounds like a significant functional regression in the UIs.

> And regardless of whether the other platforms are open or 
> proprietary, they are using open standards to print and Gutenprint's 
> current usage is causing issues.

Gutenprint's "current usage" is how it's been doing things for at least 
17 years, when driverless IPP was just a pie-in-the-sky dream.

(And if I'm not mistaken, *you* are the original author of Gutenprint's 
 CUPS glue code.  And much more..)

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?

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.

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

(BTW, it looks like Gutenprint has effectively been ghosted for a 
 *third* year in a row by a GSoC-funded student.  Why do I even try any 
 more..)

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