gimp-print-devel

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

[Erik B. of T. <ba...@ta...>]

Thank you!

On Wed, 31 Jul 2024 20:05:33 -0400
Solomon Peachy <pi...@sh...> wrote:

> On Wed, Jul 31, 2024 at 06:03:46PM -0400, Bacon At Taha wrote:
> > Are dimensions for all printers specified in points, or does that
> > vary across printers?  
> 
> Points are the unit of measurement for Postscript so that's what PPDs 
> still use.  Beyond that, printers typically represent dimensions via 
> whatever mechanism the operating system (or page definition langauge) 
> requires.  One printer I own natively uses pixels per meter, which
> IIRC is a Windows Bitmap thing.
> 
>  - Solomon

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

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

On Wed, Jul 31, 2024 at 06:03:46PM -0400, Bacon At Taha wrote:
> Are dimensions for all printers specified in points, or does that vary 
> across printers?

Points are the unit of measurement for Postscript so that's what PPDs 
still use.  Beyond that, printers typically represent dimensions via 
whatever mechanism the operating system (or page definition langauge) 
requires.  One printer I own natively uses pixels per meter, which IIRC 
is a Windows Bitmap thing.

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

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

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

On Wed, Jul 31, 2024 at 03:00:03PM -0400, Michael Sweet wrote:
> Perhaps to "fast track" this discussion, does this printer just use a 
> roll of media and cut it to the desired size?

Yes, albeit with various limitations on the allowed sizes.

(And then there are models that use discrete sheets.  Nominally they are 
 usually a "standard" size (PC, L, etc) but in reality pretty much 
 _every_ printer family differs slightly on both the physical media size 
 and the overbleed.)

> If so, the best thing to do here is report min/max roll (custom) 
> sizes, with a selection of "standard" photo sizes (as currently) that 
> are imposed on the roll with pixel duplication at the edges to avoid 
> bleed issues.  

...I'm not sure how this is supposed to work any better than what we 
have now?  After all, it's all "custom" either way.  

Meanwhile, pixel duplication for overbleed inside gutenprint is 
insufficient, as that will all but guarantee that there will be a 
visible artifact on at least one edge of the print.  

To take the CX-02 for example, in a perfect ideal world the imageable 
area is 1.5mm-2mm larger than the physical paper size. Cutting the 
imageable area down to a perfect 4x6" @300dpi means we are, at best, 
0.1mm shy of filling the paper competely on all four sides, and at worst 
(but still within spec) we could be over 2mm off on one or two sides.

> From the outside, the printer supports printing on a roll and/or 
> printing to specific "standard" sizes.  Gutenprint then handles any 
> scaling/imposition to the printer's internal buffer/roll format from 
> the raster data it gets from the print client/filters.

It is a hard requirement that there *must* be a way to say "just print 
this image as supplied, with absolutely minimal processing" -- and part 
of that is "tell me what the ideal image dimensions need to be so I can 
supply an optimized pre-scaled/sharpened/etc image."

Lying about the required image size and forcing an internal rescaling is 
completely unacceptable.

(I understand that some, maybe even most use cases don't care about 
 this, but improvements to _other_ use cases don't matter if the ones 
 you do care about cease to work!)

> Reporting non-standard sizes with standard names doesn't work on any 
> OS

Except.. this entire discussion is about how Gutenprint _isn't_ using 
standard sizes, and why can't it just do that instead?

> - macOS, for example, will report the odd sizes in the UI and any 
> CUPS-based client on Linux will likewise show odd dimensional names 
> and not the "localized" size names from the PPD file. 

That sounds like a significant functional regression in the UIs.

> And regardless of whether the other platforms are open or 
> proprietary, they are using open standards to print and Gutenprint's 
> current usage is causing issues.

Gutenprint's "current usage" is how it's been doing things for at least 
17 years, when driverless IPP was just a pie-in-the-sky dream.

(And if I'm not mistaken, *you* are the original author of Gutenprint's 
 CUPS glue code.  And much more..)

Meanwhile.  Let's suppose that everything you have said is 100% 
objectively true -- ie that Gutenprint's approach is fundamentally 
incompatible with TheWayThingsAreNowDone(tm), and large parts of it have 
to be rewritten and its overall scope greatly expanded... or what 
exactly?

Because this really sounds like I'm being "asked" to volunteer myself 
for a solid 2-3 months of unpaid full time work to produce something 
that OtherPeople(tm) want.  Then actively maintain, update, and support 
it indefinitely.  For free.

...Screw that.

Gutenprint is 100% Free Software (GPLv2+), provided AS-IS and WITHOUT 
ANY WARRANTY WHATSOEVER.  And as the sayings go, "scratch your own 
itches" and "patches welcome".

(BTW, it looks like Gutenprint has effectively been ghosted for a 
 *third* year in a row by a GSoC-funded student.  Why do I even try any 
 more..)

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

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

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

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

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

[Michael S. <ms...@ms...>]

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

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>

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

[Michael S. <ms...@ms...>]

Solomon,

Perhaps to "fast track" this discussion, does this printer just use a roll of media and cut it to the desired size?

If so, the best thing to do here is report min/max roll (custom) sizes, with a selection of "standard" photo sizes (as currently) that are imposed on the roll with pixel duplication at the edges to avoid bleed issues.  From the outside, the printer supports printing on a roll and/or printing to specific "standard" sizes.  Gutenprint then handles any scaling/imposition to the printer's internal buffer/roll format from the raster data it gets from the print client/filters.

Reporting non-standard sizes with standard names doesn't work on any OS - macOS, for example, will report the odd sizes in the UI and any CUPS-based client on Linux will likewise show odd dimensional names and not the "localized" size names from the PPD file.  And regardless of whether the other platforms are open or proprietary, they are using open standards to print and Gutenprint's current usage is causing issues.

________________________
Michael Sweet

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

[Michael S. <ms...@ms...>]

Solomon,

> On Jul 31, 2024, at 10:42 AM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> 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.

Actually, if you ran cupstestppd against the PPD file it will complain about the dimensions not matching the size (3.5x5 inches should be 252x360 points).

>> 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.

Actually, many sizes *are* standard and defined in the Adobe PPD specification.  It is just that a lot of photo printers also support other sizes that Adobe never standardized... :/

>> 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 issue is that CUPS will take the paper dimensions and convert *those* to the corresponding PWG media size name.  So 261.12x460.8 points from the previous example for the B7 size gets converted to "custom_b7_92.12x162.56mm" instead of "oe_photo-l_3.5x5in" ("L" being the photo size corresponding to 3.5x5 inches).

________________________
Michael Sweet

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

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

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)

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

[ValdikSS <ia...@va...>]

On 31.07.2024 17:42, Solomon Peachy wrote:
> 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.

Hi Solomon,
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.

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"


> 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.

I see. Should PageSize/PaperDimension use extended values in this case? 
Isn't that controlled by ImageableArea?


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

Check the link above: instead of reporting e.g. na_index-4x6_4x6in, CUPS 
reporting custom_117.35x162.56mm_117.35x162.56mm

The printer is shared by CUPS 2.4.2, cups-filters 1.28.17, gutenprint 
5.3.4.20220624T01008808d602. This is Debian 12 system.

The clients are Windows 10/11, Android 10 (check the link for more info).

If this this seem like a bug in CUPS to you, please report details here 
or to the ticket above. I'm not at all skilled in PostScript and .ppd files.

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)

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

[ValdikSS <ia...@va...>]

Hello list,

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):

...(see above)

Due to this, the software which relies on standard sizes doesn't show up 
regular page size names. 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.

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

[ValdikSS <ia...@va...>]

Hello list,

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):

|*PageSize B7/3.5x5: "<</PageSize[261.120 460.800]/ImagingBBox 
null>>setpagedevice" *PageSize w144h432/2x6: "<</PageSize[297.600 
460.800]/ImagingBBox null>>setpagedevice" *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" *PageSize w288h432-div2/2x6*2: 
"<</PageSize[297.600 460.800]/ImagingBBox null>>setpagedevice" *PageSize 
w324h432/4.5x6: "<</PageSize[332.640 460.800]/ImagingBBox 
null>>setpagedevice" *PageSize w360h360/5x5: "<</PageSize[369.600 
460.800]/ImagingBBox null>>setpagedevice" *PageSize w360h504/5x7: 
"<</PageSize[460.800 513.120]/ImagingBBox null>>setpagedevice" *PageSize 
w360h504-div2/3.5x5*2: "<</PageSize[460.800 522.240]/ImagingBBox 
null>>setpagedevice" *PageSize w360h504-w360h360_w360h144/5x5+2x5: 
"<</PageSize[460.800 513.120]/ImagingBBox null>>setpagedevice" *PageSize 
w432h432/6x6: "<</PageSize[440.640 460.800]/ImagingBBox 
null>>setpagedevice" *PageSize w432h576/6x8: "<</PageSize[460.800 
584.640]/ImagingBBox null>>setpagedevice" *PageSize 
w432h576-w432h432_w432h144/6x6+2x6: "<</PageSize[460.800 
584.640]/ImagingBBox null>>setpagedevice" *PageSize w432h576-div4/2x6*4: 
"<</PageSize[460.800 584.640]/ImagingBBox null>>setpagedevice" *PageSize 
w432h576-div2/4x6*2: "<</PageSize[460.800 599.520]/ImagingBBox 
null>>setpagedevice" *PageSize w432h648/6x9: "<</PageSize[460.800 
657.600]/ImagingBBox null>>setpagedevice" *PageSize 
w432h648-div2/4.5x6*2: "<</PageSize[460.800 672.480]/ImagingBBox 
null>>setpagedevice Due to this, the software which relies on standard 
sizes doesn't show up regular page size names. 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. |

Re: [Gimp-print-devel] (no subject)

[Erik B. of T. <ba...@ta...>]

Señor, 
Por favor eche un vistazo al siguiente enlace para darse de baja
de esta lista de correo electrónico.

https://sourceforge.net/projects/gimp-print/lists/gimp-print-devel/unsubscribe

Gracias! 

On Tue, 30 Jul 2024 22:15:42 +0200
Jesus Leyva <jes...@gm...> wrote:

> Borrarme de este correo

[Gimp-print-devel] (no subject)

[Jesus L. <jes...@gm...>]

Borrarme de este correo

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

[Erik B. of T. <ba...@ta...>]

First tweak might be to figure out why the Gutenprint GIMP plugin
doesn't observe the paper source selection, put printing from Gimp
using the same PPD/driver does.  Which might be operator error.

Cheers,

Erik


On Tue, 30 Jul 2024 08:47:32 -0400
Erik Beck of Tahoma <ba...@ta...> wrote:

> Thanks for your help!  And yes, I am guessing the tuning and tweaking
> will take some time, especially with the violet cartridge.
> 
> 
> On the patch, do you want it as a monolithic git diff patch file? And
> noted on the autogen stuff; I'll strip that out.
> 
> Regards,
> 
> Erik
> 
> 
> On Mon, 29 Jul 2024 20:57:04 -0400
> Solomon Peachy via Gimp-print-devel
> <gim...@li...> wrote:
> 
> > On Mon, Jul 29, 2024 at 03:31:22PM -0400, Erik Beck of Tahoma
> > wrote:  
> > > Now I am able to get the printer work, no core dumps in the filter
> > > chain, and can print a basic test page from Ubuntu. Yay!    
> > 
> > Excellent.  But, as I'm sure you'll discover, while you're now 90%
> > of the way there, tuning and tweaking will take up the second 90%..
> >   
> > > Some more tweaks and testing. Then try to see if I can add support
> > > for the violet cartridge in this Commercial Edition version.    
> > 
> > There are several other models that are in a similar situation.
> >   
> > > Let me know when you might want patches given the push to get this
> > > new release out.    
> > 
> > Pretty much any time is fine.  But I strongly suggest you strip out
> > all of the all of the autogenerated stuff from your working
> > repository as it will make submitting patches a lot easier.
> > 
> >  - Solomon  
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

[Erik B. of T. <ba...@ta...>]

Thanks for your help!  And yes, I am guessing the tuning and tweaking
will take some time, especially with the violet cartridge.


On the patch, do you want it as a monolithic git diff patch file? And
noted on the autogen stuff; I'll strip that out.

Regards,

Erik


On Mon, 29 Jul 2024 20:57:04 -0400
Solomon Peachy via Gimp-print-devel
<gim...@li...> wrote:

> On Mon, Jul 29, 2024 at 03:31:22PM -0400, Erik Beck of Tahoma wrote:
> > Now I am able to get the printer work, no core dumps in the filter
> > chain, and can print a basic test page from Ubuntu. Yay!  
> 
> Excellent.  But, as I'm sure you'll discover, while you're now 90% of 
> the way there, tuning and tweaking will take up the second 90%..
> 
> > Some more tweaks and testing. Then try to see if I can add support
> > for the violet cartridge in this Commercial Edition version.  
> 
> There are several other models that are in a similar situation.
> 
> > Let me know when you might want patches given the push to get this
> > new release out.  
> 
> Pretty much any time is fine.  But I strongly suggest you strip out
> all of the all of the autogenerated stuff from your working
> repository as it will make submitting patches a lot easier.
> 
>  - Solomon

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

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

On Mon, Jul 29, 2024 at 03:31:22PM -0400, Erik Beck of Tahoma wrote:
> Now I am able to get the printer work, no core dumps in the filter
> chain, and can print a basic test page from Ubuntu. Yay!

Excellent.  But, as I'm sure you'll discover, while you're now 90% of 
the way there, tuning and tweaking will take up the second 90%..

> Some more tweaks and testing. Then try to see if I can add support for
> the violet cartridge in this Commercial Edition version.

There are several other models that are in a similar situation.

> Let me know when you might want patches given the push to get this new
> release out.

Pretty much any time is fine.  But I strongly suggest you strip out all 
of the all of the autogenerated stuff from your working repository as it 
will make submitting patches a lot easier.

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

[Gimp-print-devel] Working in progress Support for Epson SC-P5000

[Erik B. of T. <ba...@ta...>]

Hi all, work done to provide basic/minimal support for this printer is
at my github repo: 
https://github.com/TahomaSoft/Gutenprint-LocalDev

See branch BasicAdd-Epson-SC-p5000
https://github.com/TahomaSoft/Gutenprint-LocalDev/tree/BasicAdd-Epson-SC-p5000

Regards,

Erik

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

[Erik B. of T. <ba...@ta...>]

It seems that adding the new xml-file-names I created to the
appropriate places in multiple Makefile.an files makes things work
better!

:+)

Now I am able to get the printer work, no core dumps in the filter
chain, and can print a basic test page from Ubuntu. Yay!

Some more tweaks and testing. Then try to see if I can add support for
the violet cartridge in this Commercial Edition version.

Let me know when you might want patches given the push to get this new
release out.

Thanks again,

Erik

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

[Erik B. of T. <ba...@ta...>]

So your hint about using cups-genppd is showing some fruit, but haven't
found the ripe apple yet.


running cups-genppd.5.3 -v cranks along fine until it reaches the ppd I
am actively working on. 

It's output is:
	Writing
	/usr/share/cups/model/gutenprint/5.3//stp-escp2-p5000-s.5.3.ppd.gz...
	Cannot find file escp2/model/model_222.xml of type escp2Model
	Aborted

However, the file model_222.xml does exist; it is the one I have
created with my chosen unique model id for this.

My working assumption is that I have something specified wrong in the
model_222.xml file or src/xml/printers/escp2.xml, or somewhere related.

Erik


On Mon, 29 Jul 2024 14:00:29 -0400
Solomon Peachy via Gimp-print-devel
<gim...@li...> wrote:

> On Mon, Jul 29, 2024 at 01:54:56PM -0400, Erik Beck of Tahoma wrote:
> > Quick question: Can the xml files for the ink, media, printer models
> > have comments in them?  I'm using <!--  --> and that may or may not
> > be part of my problem.  
> 
> IIRC comments are fine, but that doesn't mean there's not some 
> pathological corner case in the parser...
> 
>  - Solomon

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

[Erik B. of T. <ba...@ta...>]

Roger that, thanks!

Erik

On Mon, 29 Jul 2024 14:00:29 -0400
Solomon Peachy via Gimp-print-devel
<gim...@li...> wrote:

> On Mon, Jul 29, 2024 at 01:54:56PM -0400, Erik Beck of Tahoma wrote:
> > Quick question: Can the xml files for the ink, media, printer models
> > have comments in them?  I'm using <!--  --> and that may or may not
> > be part of my problem.  
> 
> IIRC comments are fine, but that doesn't mean there's not some 
> pathological corner case in the parser...
> 
>  - Solomon

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

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

On Mon, Jul 29, 2024 at 01:54:56PM -0400, Erik Beck of Tahoma wrote:
> Quick question: Can the xml files for the ink, media, printer models
> have comments in them?  I'm using <!--  --> and that may or may not be
> part of my problem.

IIRC comments are fine, but that doesn't mean there's not some 
pathological corner case in the parser...

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

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

[Erik B. of T. <ba...@ta...>]

I might be on a path...

Quick question: Can the xml files for the ink, media, printer models
have comments in them?  I'm using <!--  --> and that may or may not be
part of my problem.

Thanks,

Erik

On Mon, 29 Jul 2024 08:23:49 -0400
Solomon Peachy via Gimp-print-devel
<gim...@li...> wrote:

> On Mon, Jul 29, 2024 at 07:56:16AM -0400, Erik Beck of Tahoma wrote:
> > I ran a make check, and everything passed (4hrs 46m, 44s on an AMD
> > Ryzen 9 7900X 12-Core Processor).  
> 
> Try running 'make check-parallel'  :D
> 
> > When testing my build for this printer, rastertogutenprint crashes
> > with a signal 6 (SIGABRT).  
> 
> That's .. odd.
> 
> > Crashfile is generated with this info towards the top:
> > ProcCmdline: EPSON_SC-P5000_Series 23 erikbeck Test\ Page 1
> > job-uuid=urn:uuid:e7035dd6-08e8-303f-50b4-e8cbf5e479f9\
> > job-originating-host-name=localhost\ date-ti me-at-creation=\
> > date-time-at-processing=\ time-at-creation=1722196107\
> > time-at-processing=1722196107  
> 
> Does that automatic crash log include a core dump?  That should be
> able to tell you what went wrong where..
> 
> Also, run ./configure with --enable-debug as that will adjust the 
> compile options to make debugging easier.
> 
> > How can I test this filter outside of the normal chain so I might
> > get more insight into what is going on? Other strategies?  
> 
> This is an example of what I use to run filters in isolation:
> 
>  # pull these two from your printers.conf
>  export
> CUPS_URI="gutenprint53+usb://HiTi/P520L?serial=2WC4A1013968279"
> export
> DEVICE_URI="gutenprint53+usb://HiTi/P520L?serial=2WC4A1013968279" #
> Snag from /etc/cups/ppd or generate with cups-genppd.5.3 export
> PPD="stp-dnp-p520l.5.3.ppd" # these don't matter but need to be set
> export id="123" export user="me"
>  export title="image test"
>  export copies="1"
>  # And whatever non-default print options you want 
>  export OPTIONS="PageSize=w324h576"
> 
>  # convert image to CUPSraster (only need to do this once if the
> options or PPD don't change) /usr/lib/cups/filter/imagetoraster "$id"
> "$user" "$title" "$copies" "$OPTIONS" image.ppm > image.raster #
> generate spool file for printer (what you probably care about)
> /usr/lib/cups/filter/rastertogutenprint.5.3 "$id" "$user" "$title"
> "$copies" "$OPTIONS" image.raster > image.raw # Send it to the
> printer (optional) cat image.raw |
> /usr/lib/cups/backend/gutenprint53+usb "$id" "$user" "$title"
> "$copies" "$OPTIONS" 
> 
> 
> 
>  - Solomon

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

[Erik B. of T. <ba...@ta...>]

Thank you sir!

Good suggestions all, I will start using them and let you know how I
make out.

Regarding the core dump, yes the crash report did have one.  I'm rusty
at using gdb and other tools to look at core dumps, so I'll have to
spend some time boning back up on how to do this.

Regards,

Erik

On Mon, 29 Jul 2024 08:23:49 -0400
Solomon Peachy via Gimp-print-devel
<gim...@li...> wrote:

> On Mon, Jul 29, 2024 at 07:56:16AM -0400, Erik Beck of Tahoma wrote:
> > I ran a make check, and everything passed (4hrs 46m, 44s on an AMD
> > Ryzen 9 7900X 12-Core Processor).  
> 
> Try running 'make check-parallel'  :D
> 
> > When testing my build for this printer, rastertogutenprint crashes
> > with a signal 6 (SIGABRT).  
> 
> That's .. odd.
> 
> > Crashfile is generated with this info towards the top:
> > ProcCmdline: EPSON_SC-P5000_Series 23 erikbeck Test\ Page 1
> > job-uuid=urn:uuid:e7035dd6-08e8-303f-50b4-e8cbf5e479f9\
> > job-originating-host-name=localhost\ date-ti me-at-creation=\
> > date-time-at-processing=\ time-at-creation=1722196107\
> > time-at-processing=1722196107  
> 
> Does that automatic crash log include a core dump?  That should be
> able to tell you what went wrong where..
> 
> Also, run ./configure with --enable-debug as that will adjust the 
> compile options to make debugging easier.
> 
> > How can I test this filter outside of the normal chain so I might
> > get more insight into what is going on? Other strategies?  
> 
> This is an example of what I use to run filters in isolation:
> 
>  # pull these two from your printers.conf
>  export
> CUPS_URI="gutenprint53+usb://HiTi/P520L?serial=2WC4A1013968279"
> export
> DEVICE_URI="gutenprint53+usb://HiTi/P520L?serial=2WC4A1013968279" #
> Snag from /etc/cups/ppd or generate with cups-genppd.5.3 export
> PPD="stp-dnp-p520l.5.3.ppd" # these don't matter but need to be set
> export id="123" export user="me"
>  export title="image test"
>  export copies="1"
>  # And whatever non-default print options you want 
>  export OPTIONS="PageSize=w324h576"
> 
>  # convert image to CUPSraster (only need to do this once if the
> options or PPD don't change) /usr/lib/cups/filter/imagetoraster "$id"
> "$user" "$title" "$copies" "$OPTIONS" image.ppm > image.raster #
> generate spool file for printer (what you probably care about)
> /usr/lib/cups/filter/rastertogutenprint.5.3 "$id" "$user" "$title"
> "$copies" "$OPTIONS" image.raster > image.raw # Send it to the
> printer (optional) cat image.raw |
> /usr/lib/cups/backend/gutenprint53+usb "$id" "$user" "$title"
> "$copies" "$OPTIONS" 
> 
> 
> 
>  - Solomon