Re: Citizen CX-02 incorrect paper dimensions in PPD

PPD files use points for all printers... Not sure what the internal units are for Gutenprint...


> On Jul 31, 2024, at 6:03 PM, Bacon At Taha <[email protected]> wrote:
> 
> 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 <[email protected]> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>> <signature.asc>
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

________________________
Michael Sweet



_______________________________________________
Gimp-print-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel