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

[Bacon At T. <ba...@ta...>]

Are dimensions for all printers specified in points, or does that vary across printers?

Thanks,

Erik
Sent from my iPhone

> On Jul 31, 2024, at 13:06, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Wed, Jul 31, 2024 at 06:13:11PM +0300, ValdikSS wrote:
>> I'd expect 3.5x5 PageSize to contain "252 360" value instead of "261.120
>> 460.800".
>> If I modify .ppd file with the values calculated by multiplying inches by
>> 72, CUPS starts to report these values as an IPP-defined media sizes.
> 
> Again, this printer does not support "standard paper sizes" -- it _only_
> uses printer-specific rolls of media.
> 
> It reports as 251.120 because *that is the actual dimension the
> printer needs*
> 
> If we report it as something smaller, then CUPS will hand us a raster
> image that is smaller than the printer needs, and that will make users
> very unhappy.
> 
>> Michael Sweet, the developer of CUPS, told to report this as a bug to you:
>> https://github.com/OpenPrinting/cups/issues/1017#issuecomment-2259205981
>> 
>> Also I'm not sure why there are same PageSize values used for different page
>> sizes, for example:
>> 
>> *PageSize w243h432/3.375x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>> null>>setpagedevice"
>> *PageSize w270h432/3.75x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>> null>>setpagedevice"
>> *PageSize w288h432/4x6:    "<</PageSize[297.600 460.800]/ImagingBBox
>> null>>setpagedevice"
> 
> Except it's _not_ the same PageSize; they have different identifiers.  
> Additionally, the ImageableAreas corresponding to those identifiers are
> different.
> 
> But... so what?  Even if the parameters were 100% identical, they are
> uniquely named, and those unique names are what clients are supposed to
> use to disambiguate things.
> 
>> I see. Should PageSize/PaperDimension use extended values in this case?
>> Isn't that controlled by ImageableArea?
> 
> I would think ImageableArea is more important than PageSize in this
> context, yes.
> 
>> Check the link above: instead of reporting e.g. na_index-4x6_4x6in, CUPS
>> reporting custom_117.35x162.56mm_117.35x162.56mm
> 
> That's because from the printer's perspective, it's physicaly larger
> than a "true" 4x6in print.
> 
> It is my understanding that the ImageableArea must be entirely contained
> within the PageSize.  Given that we need an ImageableArea physically
> larger than a "true" 4x6in print... that means we can't claim to be 4x6.
> So we don't.
> 
> ...Putting aside the less-than-ideal name, does it actually _work_ and
> print as expected?
> 
> Because this appears to be purely a cosmetic issue, brought on by how
> CUPS auto-translates PPD PageSize+ImageableArea into IPP's
> media+media-col equivalents.
> 
> A native IPP gutenprint print application would presumably be able to do
> better here; however at the end of the day the CX-02 (and other printers
> of its general class) do not use "standard" paper sizes, and I don't
> know what the implications could be if we report the "nominal" media
> name while correcting/supplenting the specifics in other attributes.
> 
> Based on my direct experience with IPP, if you're not using "standard
> office-type" paper sizes then for a realistic chance of success, you're
> probably going to have to use a vendor "app" to do the printing instead
> of "standard" IPP -- and that's using _native_ IPP printers, taking
> gutenprint + CUPS out of the loop entirely!
> 
> (As an aside, it is both faster and more reliable to print to my Brother
> Laser printer via IPP->CUPS->Gutenprint->JetDirect than it is to use the
> printer's native driverless IPP functionality.  Even from an iPhone!)
> 
> This new IPP world is two orders of magnitude more complicated, and I'm
> just one person working on this stuff on a (very) part time,
> entirely-out-of-pocket basis.
> 
>> The clients are Windows 10/11, Android 10 (check the link for more info).
> 
> At the end of the day I simply *do not care one iota* for supporting or
> resolving printing problems on proprietary platforms or operating
> systems.  If those platform owners (and printer manufacturers!) care,
> then they can do (and/or properly fund) this work themselves.
> 
> I'm <this> close to saying "eff this BS" and walking away entirely,
> because it's at the point where replacing fence posts while having my
> blood rapidly drained by swarms of mosquitos a moderate drizzle is more
> personally rewarding than continuing to deal with trying to keep
> printing working.
> 
> (Apologies for the rant, but ..... )
> 
> - 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
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> <signature.asc>