Menu
▾
▴
Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD
|
From: Bacon At T. <ba...@ta...> - 2024-07-31 22:36:42
|
Thank you Michael, that is helpful. Sent from my iPhone > On Jul 31, 2024, at 18:14, Michael Sweet via Gimp-print-devel <gim...@li...> wrote: > > 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 <ba...@ta...> 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 <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> >> >> >> _______________________________________________ >> Gimp-print-devel mailing list >> Gim...@li... >> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel > > ________________________ > Michael Sweet > > > > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
