gimp-print-devel

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

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

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

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
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)

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

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

Hello all,

I could use some help on debugging strategies for rastertogutenprint.

I am working on supporting an Epson SureColor P-5000, using the latest
interim release of 5.3.5-pre1.

I ran a make check, and everything passed (4hrs 46m, 44s on an AMD
Ryzen 9 7900X 12-Core Processor).

When testing my build for this printer, rastertogutenprint crashes with
a signal 6 (SIGABRT).

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


How can I test this filter outside of the normal chain so I might get
more insight into what is going on? Other strategies?

Thanks!

Erik

Re: [Gimp-print-devel] Printer problem with brother HL-1112R

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

On Sat, Jul 20, 2024 at 02:35:10PM +0300, serwer2008--- via Gimp-print-devel wrote:
> Is it possible to include it in the list of supported devices printer 
> brother HL-1112R? Brother HL-1112R printer dose not works in haiku os. 
> I tried all printer drivers, different models. The guteprint driver 
> was used.

The HL-1112 appears to be a minimal PCL5e-based device.

So try using "generic PCL5 printer" or "Laserjet 5L"

Best of luck,

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

[Gimp-print-devel] (no subject)

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

Cuents

[Gimp-print-devel] Printer problem with brother HL-1112R

[<ser...@ic...>]

Dear developers,
Is it possible to include it in the list of supported devices printer brother HL-1112R? Brother HL-1112R printer dose not works in haiku os. I tried all printer drivers, different models. The guteprint driver was used.
Best wishes,
Vanya
Картинкиdriver was used.The printer is fully operational.

Re: [Gimp-print-devel] Gutenprint 5.3.5-pre1 Release

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

I definitely support fleeing from source forge.
Sent from my iPhone

> On Jul 9, 2024, at 18:29, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Tue, Jul 09, 2024 at 07:49:34PM -0400, Greg Troxel wrote:
>> This really seems buggy of sourceforge, and seems to be hostile to
>> packaging.  I am guessing this is just how it is, and there's not much
>> to be done, other than skipping github and moving to codeberg :-)
> 
> I'd probably jump straight to sourcehut instead, because I prefer email.
> 
> ...just have to get this release out the door before I can figure out 
> what to do next.  I'd rather self-host than stay on sourceforge.
> 
>> I am curious if other packagers also find this troublesome.  They might
>> well not; this is just a collision between pkgsrc assuming
>> near-universal practice and sourceforge being odd.
> 
> I honestly don't know.
> 
>>>  0) Support for running on MacOS has been deprecated. Unless someone
>>>     steps up to maintain the MacOS port, there will be no MacOS
>>>     builds for this (or any future) Gutenprint release.
>> 
>> I'm hoping that a posix-type build on macos is ok, but if not we can
>> mark the pkgsrc package BROKEN.
> 
> Given that we have to integrate with the MacOS printing subsystem and 
> directly speak to attached USB devices, I don't believe a posix-type 
> build has been sufficient for something like a decade..
> 
> - 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] Gutenprint 5.3.5-pre1 Release

[Matt B. <wal...@ma...>]

> On Jul 11, 2024, at 9:26 AM, Greg Troxel <gd...@le...> wrote:
> 
> Solomon Peachy via Gimp-print-devel
> <gim...@li...> writes:
> 
>> On Wed, Jul 10, 2024 at 08:26:56PM -0400, Greg Troxel wrote:
>>> Strictly, a program should specify --std=cNN for the variant it is
>>> written in.  But I think the default -- so far -- is almost always c99
>>> so often this doesn't happen.
>> 
>> gcc jumped from 'gnu89' straight to 'gnu11' and currently defaults to 
>> 'gnu17'.  At no point did GCC ever default to c99 (or gnu99).
> 
> Wow, but I learn something new every day.  Anyway, I think we'll all
> happy with --std=c99.
> 
>>> I ran make check, and it passed ppds and is still going.
>> 
>> This will take some hours depending on the speed of your system.
> 
> It took 12 hours, and that's on a 9th-gen i7!  But I got a clean pass.
> 
>> What does 'man strdup' and 'man localtime_r' list as requirements for 
>> use on these problematic platforms?
> 
> On NetBSD, strdup says the following (leaving out stuff in the middle)
> and it works without any defines.
> 
>  SYNOPSIS
>       #include <string.h>
> 
>       char *
>       strdup(const char *str);
> 
>       char *
>       strndup(const char *str, size_t len);
> 
>  STANDARDS
>       The strdup() function conforms to IEEE Std 1003.1-2001 (“POSIX.1”).
> 
>  HISTORY
>       The strdup() function first appeared in 4.4BSD.  The strndup() function
>       was added in NetBSD 4.0.
> 
> man localtime_r says:
> 
>  SYNOPSIS
>       #include <time.h>
> 
>       struct tm *
>       localtime_r(const time_t * restrict clock, struct tm * restrict result);
> 
>  STANDARDS
>       The ctime(), difftime(), asctime(), localtime(), gmtime() and mktime()
>       functions conform to ANSI X3.159-1989 (“ANSI C89”).  Rest of the
>       functions conform to IEEE Std 1003.1-2008 (“POSIX.1”).
> 

macos 12.7.5 responds as--
man strdup
NAME
     strdup, strndup – save a copy of a string

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <string.h>

     char *
     strdup(const char *s1);

     char *
     strndup(const char *s1, size_t n);

DESCRIPTION
     The strdup() function allocates sufficient memory for a copy of the string
     s1, does the copy, and returns a pointer to it.  The pointer may
     subsequently be used as an argument to the function free(3).

     If insufficient memory is available, NULL is returned and errno is set to
     ENOMEM.

     The strndup() function copies at most n characters from the string s1
     always NUL terminating the copied string.

SEE ALSO
     free(3), malloc(3)

HISTORY
     The strdup() function first appeared in 4.4BSD.  The strndup() function was
     added in FreeBSD 7.2.

macOS 12.7                      December 5, 2008                      macOS 12.7

=======================================
man localtime_r
CTIME(3)                    Library Functions Manual                    CTIME(3)

NAME
     asctime, asctime_r, ctime, ctime_r, difftime, gmtime, gmtime_r, localtime,
     localtime_r, mktime, timegm, timelocal – transform binary date and time
     values

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <time.h>

     extern char *tzname[2];

     char *
     asctime(const struct tm *timeptr);

...

SEE ALSO
     date(1), gettimeofday(2), getenv(3), time(3), tzset(3), tzfile(5)

STANDARDS
     The asctime(), ctime(), difftime(), gmtime(), localtime(), and mktime()
     functions conform to ISO/IEC 9899:1990 (“ISO C90”), and conform to ISO/IEC
     9945-1:1996 (“POSIX.1”) provided the selected local timezone does not
     contain a leap-second table (see zic(8)).

     The asctime_r(), ctime_r(), gmtime_r(), and localtime_r() functions are
     expected to conform to ISO/IEC 9945-1:1996 (“POSIX.1”) (again provided the
     selected local timezone does not contain a leap-second table).

     The timegm() function is not specified by any standard; its function cannot
     be completely emulated using the standard functions described above.

HISTORY
     This manual page is derived from the time package contributed to Berkeley
     by Arthur Olson and which appeared in 4.3BSD.

BUGS
     Except for difftime(), mktime(), and the _r() variants of the other
     functions, these functions leaves their result in an internal static object
     and return a pointer to that object.  Subsequent calls to these function
     will modify the same object.

     The C Standard provides no mechanism for a program to modify its current
     local timezone setting, and the POSIX-standard method is not reentrant.
     (However, thread-safe implementations are provided in the POSIX threaded
     environment.)

     The tm_zone field of a returned tm structure points to a static array of
     characters, which will also be overwritten by any subsequent calls (as well
     as by subsequent calls to tzset(3) and tzsetwall(3)).

     Use of the external variable tzname is discouraged; the tm_zone entry in
     the tm structure is preferred.

macOS 12.7                       January 2, 1999                      macOS 12.7

Matt

Re: [Gimp-print-devel] Gutenprint 5.3.5-pre1 Release

[Greg T. <gd...@le...>]

Solomon Peachy via Gimp-print-devel
<gim...@li...> writes:

> On Wed, Jul 10, 2024 at 08:26:56PM -0400, Greg Troxel wrote:
>> Strictly, a program should specify --std=cNN for the variant it is
>> written in.  But I think the default -- so far -- is almost always c99
>> so often this doesn't happen.
>
> gcc jumped from 'gnu89' straight to 'gnu11' and currently defaults to 
> 'gnu17'.  At no point did GCC ever default to c99 (or gnu99).

Wow, but I learn something new every day.  Anyway, I think we'll all
happy with --std=c99.

>> I ran make check, and it passed ppds and is still going.
>
> This will take some hours depending on the speed of your system.

It took 12 hours, and that's on a 9th-gen i7!  But I got a clean pass.

> What does 'man strdup' and 'man localtime_r' list as requirements for 
> use on these problematic platforms?

On NetBSD, strdup says the following (leaving out stuff in the middle)
and it works without any defines.

  SYNOPSIS
       #include <string.h>

       char *
       strdup(const char *str);

       char *
       strndup(const char *str, size_t len);

  STANDARDS
       The strdup() function conforms to IEEE Std 1003.1-2001 (“POSIX.1”).

  HISTORY
       The strdup() function first appeared in 4.4BSD.  The strndup() function
       was added in NetBSD 4.0.

man localtime_r says:

  SYNOPSIS
       #include <time.h>

       struct tm *
       localtime_r(const time_t * restrict clock, struct tm * restrict result);

  STANDARDS
       The ctime(), difftime(), asctime(), localtime(), gmtime() and mktime()
       functions conform to ANSI X3.159-1989 (“ANSI C89”).  Rest of the
       functions conform to IEEE Std 1003.1-2008 (“POSIX.1”).


>> I don't have an inkjet printer any more, but from my viewpoint the only
>> thing wrong is the POSIX_C_SOURCE define.
>
> Upstream will _not_ apply this as it will break compilation on 
> bog-standard Linux systems.

I am not really saying you should never define it.  Just that you should
only define it on systems known to need it, where any remediation of
defining additional visibility defines can be done.

When you use a visibility define, then the system is supposed to hide
everything that is not required by that define.  I am unclear on the
relationship of system headers to these, specifically if there is an
expectation that system headers that are *not* required by that posix
level will work.  People often (on NetBSD) define _NETBSD_SOURCE, to get
back the things that are beyond posix that are defined by NetBSD.

I find it strange that strdup is not available on Linux without a define,
given that it has been in base posix since 2001 and is from 4.4BSD which
is roughly contemperaneous with the start of Linux.  But if that's how
it is that's how it is.

I compiled this hacky test program on Raspberry Pi OS 12 (which is
~debian):

  #include <string.h>

  int
  main()
  {
    char *a, *b;

    a = "foo";

    b = strdup(a);

    return 0;
  }

and it compiled without warnings.  It also compiled without warnings on
real Debian 12 (x86_64), which has gcc 12.2.0.



If you aren't willing to basically guard the _POSIX_C_SOURCE define with
"#if linux", then please at least omit it if NetBSD or macOS.  It is
likely it needs to be omitted the rest of the BSDs as well.



I append NetBSD's sys/featuretest.h.   As far as I know this is what is
supposed to happen.

  /*      $NetBSD: featuretest.h,v 1.10 2013/04/26 18:29:06 christos Exp $        */

  /*
   * Written by Klaus Klein <kl...@Ne...>, February 2, 1998.
   * Public domain.
   *
   * NOTE: Do not protect this header against multiple inclusion.  Doing
   * so can have subtle side-effects due to header file inclusion order
   * and testing of e.g. _POSIX_SOURCE vs. _POSIX_C_SOURCE.  Instead,
   * protect each CPP macro that we want to supply.
   */

  /*
   * Feature-test macros are defined by several standards, and allow an
   * application to specify what symbols they want the system headers to
   * expose, and hence what standard they want them to conform to.
   * There are two classes of feature-test macros.  The first class
   * specify complete standards, and if one of these is defined, header
   * files will try to conform to the relevant standard.  They are:
   *
   * ANSI macros:
   * _ANSI_SOURCE                 ANSI C89
   *
   * POSIX macros:
   * _POSIX_SOURCE == 1           IEEE Std 1003.1 (version?)
   * _POSIX_C_SOURCE == 1         IEEE Std 1003.1-1990
   * _POSIX_C_SOURCE == 2         IEEE Std 1003.2-1992
   * _POSIX_C_SOURCE == 199309L   IEEE Std 1003.1b-1993
   * _POSIX_C_SOURCE == 199506L   ISO/IEC 9945-1:1996
   * _POSIX_C_SOURCE == 200112L   IEEE Std 1003.1-2001
   * _POSIX_C_SOURCE == 200809L   IEEE Std 1003.1-2008
   *
   * X/Open macros:
   * _XOPEN_SOURCE                System Interfaces and Headers, Issue 4, Ver 2
   * _XOPEN_SOURCE_EXTENDED == 1  XSH4.2 UNIX extensions
   * _XOPEN_SOURCE == 500         System Interfaces and Headers, Issue 5
   * _XOPEN_SOURCE == 520         Networking Services (XNS), Issue 5.2
   * _XOPEN_SOURCE == 600         IEEE Std 1003.1-2001, XSI option
   * _XOPEN_SOURCE == 700         IEEE Std 1003.1-2008, XSI option
   *
   * NetBSD macros:
   * _NETBSD_SOURCE == 1          Make all NetBSD features available.
   *
   * If more than one of these "major" feature-test macros is defined,
   * then the set of facilities provided (and namespace used) is the
   * union of that specified by the relevant standards, and in case of
   * conflict, the earlier standard in the above list has precedence (so
   * if both _POSIX_C_SOURCE and _NETBSD_SOURCE are defined, the version
   * of rename() that's used is the POSIX one).  If none of the "major"
   * feature-test macros is defined, _NETBSD_SOURCE is assumed.
   *
   * There are also "minor" feature-test macros, which enable extra
   * functionality in addition to some base standard.  They should be
   * defined along with one of the "major" macros.  The "minor" macros
   * are:
   *
   * _REENTRANT
   * _ISOC99_SOURCE
   * _ISOC11_SOURCE
   * _LARGEFILE_SOURCE            Large File Support
   *              <http://ftp.sas.com/standards/large.file/x_open.20Mar96.html>
   */

  #if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE)
  #define _POSIX_C_SOURCE 1L
  #endif

  #if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
      !defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
  #define _NETBSD_SOURCE 1
  #endif

  #if ((_POSIX_C_SOURCE - 0) >= 199506L || (_XOPEN_SOURCE - 0) >= 500) && \
      !defined(_REENTRANT)
  #define _REENTRANT
  #endif