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

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

On Wed, Jul 31, 2024 at 04:29:42AM +0300, ValdikSS via Gimp-print-devel wrote:
> Citizen CX-02 PPD file contains the following sizes, using what it seems
> should have been PageRegion/ImageableArea for whatever reason (the
> dimensions are slightly larger than the described page sizes):

I'm having a very hard time following what you pasted here, so I'll 
extract the definitions for one size from the PPD:

*PageSize B7/3.5x5:     "<</PageSize[261.120 460.800]/ImagingBBox null>>setpagedevice"
*ImageableArea B7/3.5x5:        "0.000 44.640 261.120 416.160"
*PaperDimension B7/3.5x5:       "261.120 460.800"

PageSize and PaperDimension are identical, and ImageableArea is smaller 
because of how the printer works.

....This appears to be perfectly fine and is completely compliant with 
PPD-based printing flows, which one would expect for something designed 
around PPDs.

> The software which relies on standard sizes doesn't show up regular 
> page size names.

There is no such thing as a "standard size" from the PPD's perspective; 
they enumerate what they support (using an arbitrary identifier and 
UI-visible name) and provide the appropriate dimensions.

> When the printer is shared in CUPS over IPP, IPP reports only a set of 
> custom page sizes instead of a standard sizes, and some clients can't 
> handle that. This seems like a bug. |

Again, what do you mean by "standard sizes"?  The printer supports what 
it supports, nothing more.  For example. the CX-02's native resolution 
at 300dpi is 1844x1240, which equates to 15.37x10.33 cm, and in the PPD 
we assign it the ID of "w288h432" and UI-visible name of "4x6" for a 
"standard" 4x6" or 10x15cm print.

The CX-02 is a full-bleed printer; in order to guarantee edge-to-edge 
printing the image data has to extend past the physical edges of the 
paper. So if we lie about the supported resolution (eg 1800x1200 for a 
perfect 10x15cm at 300dpi) then if we don't lossily re-scale the image 
to fit the printer's native resolution, we are all but guaranteed to end 
up with visible white margins on at least one edge of the print.

...Meanwhile, you didn't say what version of cups, cups-filters, or 
gutenprint is in use, nor what IPP client is exhibiting this 
misbehavior.

Gutenprint has no IPP capabilities at all, so any IPP-related bugs are 
due to whatever is implementing IPP on top of it.  All necessary 
information is already provided by Gutenprint, so either CUPS' IPP 
translation/re-exporting of the PPD data is improperly converting this 
into native IPP representation, or the IPP client is ignoring it.  
Either way there's nothing Gutenprint can do about it. [1]

[1] Beyond writing our own IPP integration layer.

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