Menu
▾
▴
Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD
|
From: Michael S. <ms...@ms...> - 2024-07-31 22:14:19
|
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 |
