gimp-print-devel

[Gimp-print-devel] Gutenprint Printer Application (Native)

[Till K. <til...@gm...>]

Hi,

I have created a Gutenprint Printer Application by retro-fitting 
Gutenprint's CUPS driver into a Printer Application using PAPPL 
(https://github.com/michaelrsweet/pappl) and my CUPS driver retro-fit 
library pappl-retrofit (https://github.com/OpenPrinting/pappl-retrofit):

https://github.com/OpenPrinting/gutenprint-printer-app
https://snapcraft.io/gutenprint-printer-app

Note that this is only an interim effort, as the right way to make a 
Printer Application out of Gutenprint is a native Printer Apoplication, 
not using PPDs, the CUPS filter, and the CUPS backend of Gutenprint, but 
instead, use only PAPPL and libgutenprint. Therefore I will maintain 
this Printer Application only as long as there is no native Gutenprint 
Printer Application from the Gutenprint project, once that is there, I 
will discontinue my Printer Application.

Note that the retro-fit is not perfect, especially due to the restricted 
number of vendor-specific options in PAPPL I could base my Printer 
Application only on the simplified PPDs and not on the expert ones.

I also included the CUPS backend for dye-sub printers but could not 
actually test it.

So please test my Printer Applications on printers which I do not have 
(I only have the HP OfficeJet Pro 8730, which my Gutenprint Printer 
Application sets up as PCL Color Laser). Issue reports and pull requests 
are more than welcome.

Sambhav, still working on a native Gutenprint Printer Application?

I hope my Printer Application will give some inspiration towards the 
development of a native Gutenprint Printer Application.

    Till

Re: [Gimp-print-devel] your plug-in or app for iMac running Big Sur ...

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

> On Sep 16, 2021, at 2:59 PM, SMYTH Bart <bs...@gm...> wrote:
> 
> 
> Hello —
> 
> I’m currently running Catalina on my iMac and have your program installed so I can continue to print with my Epson Workforce 30 for which I'm very grateful to you.
> 
> The thing is that I’m being pressured into upgrading to Mac OS Big Sur partly because of this spyware called Pegasus. However, if I can’t use my Epson WF30 printer I’m being very reluctant to go up to Big Sur.
> 
> So, do you have a version of your software that will allow me to print on this printer if my Mac is running Big Sur?

The current version of the macos drivers -- gutenprint-5.3.3_rev.dmg <https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.3/gutenprint-5.3.3_rev.dmg/download> -- will work with Mac OS X 10.7.x thru Big Sur.  You may need to reinstall the drivers after the upgrade.  Apple has been known to remove third party drivers during an upgrade.

Matt

Re: [Gimp-print-devel] 'commandtoepson' revamping?

[Robert K. <rl...@al...>]

On 9/16/21 8:43 AM, Solomon Peachy wrote:
> I'd like to change 'commandtoepson' to work the way CUPS expects, and 
> add the filter to the PPD so CUPS can invoke it automatically, but this 
> would require an implementation change so that it doesn't trigger a 
> print.
> 
> This would be broadly applicable to any printer escputil can work with, 
> so it probably makes sense to enable it across the board for the entire 
> escp2 family (perhaps with a blacklist) rather than only enabling it for 
> specific models.
> 
> Thoughts?
> 
> (The dyesub backend acually implements this command filter functionality 
>  already, but I never did hook it up to the PPDs)

This is going to need some pretty thorough testing.  Unfortunately, I don't have many old printers
any more, so there's going to need to be some kind of graceful failure.

[Gimp-print-devel] your plug-in or app for iMac running Big Sur ...

[SMYTH B. <bs...@gm...>]

Hello —

I’m currently running Catalina on my iMac and have your program installed so I can continue to print with my Epson Workforce 30 for which I'm very grateful to you.

The thing is that I’m being pressured into upgrading to Mac OS Big Sur partly because of this spyware called Pegasus. However, if I can’t use my Epson WF30 printer I’m being very reluctant to go up to Big Sur.

So, do you have a version of your software that will allow me to print on this printer if my Mac is running Big Sur?

Bart Smyth
(412) 576-8448

•

 

[Gimp-print-devel] 'commandtoepson' revamping?

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

I've been looking at how to get escp2 printer status and ink level 
reporting back up through the CUPS stack.  This is normally done via 
inline ATTRs via the normal print filter flow, but can also be done 
using an out-of-band "command filter".

I saw that there is an existing 'commandtoepson' filter, but it's not 
hooked up through our generated PPDs, so CUPS doesn't know it exists.  
Digging a little further I discovered that due to how it's written, the 
'ReportLevels' command trigges a physical printout rather than just 
querying and returning (ala escputil) the status/levels as ATTRs that 
CUPS expects and can report to the user:

  https://www.cups.org/doc/spec-command.html#ReportLevels

I'd like to change 'commandtoepson' to work the way CUPS expects, and 
add the filter to the PPD so CUPS can invoke it automatically, but this 
would require an implementation change so that it doesn't trigger a 
print.

This would be broadly applicable to any printer escputil can work with, 
so it probably makes sense to enable it across the board for the entire 
escp2 family (perhaps with a blacklist) rather than only enabling it for 
specific models.

Thoughts?

(The dyesub backend acually implements this command filter functionality 
 already, but I never did hook it up to the PPDs)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

Re: [Gimp-print-devel] Printer support_question

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

> On Sep 13, 2021, at 1:49 PM, Max Fomin <fo...@gm...> wrote:
> 
> Hello! 
> Please tell me if it is possible to add the Xerox Phaser 3140-3155 to the list of supported printers? Unfortunately, this model is no longer supported on macOS BigSUR. Thanks in advance for your reply.
> 

Unfortunately Gutenprint will not be able to support this printer.  It relies on a proprietary printer language developed by Xerox.

Matt

Re: [Gimp-print-devel] Does not work on Brother HL-5170DN

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

<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="ApplePlainTextBody"><div class="ApplePlainTextBody"><br><br><blockquote type="cite">On Sep 13, 2021, at 8:32 PM, Barry Gehm &lt;bar...@ly...&gt; wrote:<br><br>Hi,<br>I downloaded and installed Gutenprint 5.3.3 on my mid-2012 MacBook Pro running Catalina (10.15.7) and attempted to use it with my Brother HL-5170DN printer. &nbsp;Although the installation appeared to go smoothly, attempting to print using the Gutenprint driver resulted in the printer just spitting out page after page of printed error messages (one per page). &nbsp;The same thing happens when I attempt to use the Brother CUPS driver, although the BRscript-3 driver works.<br></blockquote><br>Thank you for your interest in the Gutenprint drivers. &nbsp;It appears to me that the printer is not responding to the PCL language. &nbsp;That would be the printer language used in the Brother CUPS and the Gutenprint drivers. &nbsp;The garbage output is presumably PostScript/BrushScript code. &nbsp;The BrushScript driver is a PostScript driver. &nbsp;Normally, a printer will automatically change modes to whatever print language it is sent. Perhaps others here might have some more insight.<br>Matt<br><br></div></body></html>

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[jsmeix <js...@su...>]

Hello,

On 2021-09-11 17:51, Robert Krawitz wrote:
> On 9/9/21 7:58 AM, jsmeix wrote:
>> From my own experience about 30 years ago I remember
>> that in practice
>> "there is no such thing as 'equal' with float data types".
>> 
>> I.e. code that is based on 'float1 == float2' cannot work
>> reliably in general because even if float1 and float2
>> must me mathematically identical it does not mean their
>> representations as a limited sequences of bits are same.
> 
> That's certainly true, but the converse (that
> inequality comparisons are safe) is not necessarily
> true (even strict inequality comparisons,
> e. g. < vs. <=, aren't always safe for numbers
> that can't be represented exactly).

Yes, of course.
That's what I meant with "based on 'float1 == float2'".
E.g. 'float1 < float2' is based on 'float1 == float2'
because when one cannot safely/reliably determine
when 'float1 == float2' holds then one also cannot
safely/reliably determine when 'float1 < float2' holds
because 'float1 < float2 <=> 'NOT float1 >= float2' and
'float1 >= float2' <=> 'float1 > float2' OR 'float1 == float2'
so 'float1 < float2' needs (is based on) 'float1 == float2'.


> We may need to implement small fudge factors,
> maybe something like 0.000001 point

I would not call it "fudge" because it is not about
to somehow "cheat" a bit here but the contrary:
It is about to ignore meaningless aritfacts
of differences in some least significant bits.
I.e. ignoring such meaningless aritfacts
makes things working correct.


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

[Gimp-print-devel] Does not work on Brother HL-5170DN

[Barry G. <bar...@ly...>]

Hi,
I downloaded and installed Gutenprint 5.3.3 on my mid-2012 MacBook Pro
running Catalina (10.15.7) and attempted to use it with my Brother
HL-5170DN printer.  Although the installation appeared to go smoothly,
attempting to print using the Gutenprint driver resulted in the printer
just spitting out page after page of printed error messages (one per
page).  The same thing happens when I attempt to use the Brother CUPS
driver, although the BRscript-3 driver works.

Just FYI.

*BARRY D. GEHM, PHD * |  Asst. Prof. of Chemistry/Biochemistry
[image: Lyon Logo] <https://www.lyon.edu/>

2300 Highland Road
Batesville, AR 72501
*OFFICE  *(870) 307-7282
*FAX  *(870) 307-7496
*WEB  *lyon.edu <https://www.lyon.edu/>

*“PERSEVERANCE CONQUERS ALL, GOD WILLING”*

[image: Facebook] <http://www.facebook.com/lyoncollege> [image: Twitter]
<https://twitter.com/lyoncollege> [image: YouTube]
<https://www.youtube.com/channel/UCSL_oLHMShWVkAq_RPM520Q> [image: LinkedIn]
<http://www.linkedin.com/company/lyon-college> Subscribe to the @Lyon
Newsletter! <https://www.lyon.edu/lyon-newsletter>

*Views expressed in this email are not necessarily those of Lyon College.*

[Gimp-print-devel] Printer support_question

[Max F. <fo...@gm...>]

Hello!
Please tell me if it is possible to add the Xerox Phaser 3140-3155 to the
list of supported printers? Unfortunately, this model is no longer
supported on macOS BigSUR. Thanks in advance for your reply.


-------------
Best regards, Max.

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[Robert K. <rl...@al...>]

On 9/9/21 7:58 AM, jsmeix wrote:
> From my own experience about 30 years ago I remember
> that in practice
> "there is no such thing as 'equal' with float data types".
> 
> I.e. code that is based on 'float1 == float2' cannot work
> reliably in general because even if float1 and float2
> must me mathematically identical it does not mean their
> representations as a limited sequences of bits are same.

That's certainly true, but the converse (that inequality comparisons are safe) is not necessarily
true (even strict inequality comparisons, e. g. < vs. <=, aren't always safe for numbers that can't
be represented exactly). We may need to implement small fudge factors, maybe something like 0.000001
point, for things that aren't exact (i. e. dyesub) or round the check functions up to the larger
integer number of points for comparison.

[Gimp-print-devel] Guterprint Support Ubuntu?

[Jake S. <jak...@gm...>]

Is it compatible with Ubuntu?

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[jsmeix <js...@su...>]

Hello,

sorry for the delay - I was busy with other tasks.

On 2021-09-06 01:26, Solomon Peachy wrote:
> On Sun, Sep 05, 2021 at 06:16:10PM -0400, Robert Krawitz wrote:
>> Sigh...have to figure out how to fix this.  Maybe we have to allow
>> something like a millipoint of slop.  Interesting that it seems to
>> have only hit the dyesub printers; is the issue that those are the
>> only ones with non-integer widths (in points)?
> 
> Yeah, I can't speak for every other family but inside the dyesub 
> driver,
> all dimensions are specified in terms of pixels, but converted to 
> points
> for external consumption.
> 
> I think it's reasonable to truncate anything smaller than a millipoint,
> though just patching that failing test to allow for a little slop seems
> like a bandaid when there very may well be other related lurking issues 
> that
> are ultimately due to a platform-specific FP semantics problem.
> 
> So I question whether Gutenprint is relevant for a >20-year-old
> Pentium3-era PC -- and this OpenSUSE build is actually targeting even
> older Pentium1-era systems that a $5 Raspberry Pi Zero would easily run
> circles around.

I have no influence for what exact 32-bit x86 architecure
packages for openSUSE_Tumbleweed for 32-bit x86 are built.
I assume "i586" was chosen intentionally and I guess
it was chosen as some generic most common most basic thing
so that packages that are built this way reall work on
any 32-bit x86 hardware that is still "out there" without
restrictions to only some "newer" 32-bit x86 hardware.
Bottom line:
I cannot change that so I have to use it as is.

> Perhaps the correct thing to do is force these older targets to use
> "correct" IEEE754 FP math through some extra GCC flags (-ffloat-store
> might be sufficient), which would hurt performance (on an already
> relatively glacial platform) but would mean we'd not need to make
> otherwise unnecessary algorithmic spelunking..

Unfortunately -ffloat-store does not help.

I made a separated gutenprint53t package at
https://build.opensuse.org/project/show/home:jsmeix

There -ffloat-store is set if arch is not x86_64 see
https://build.opensuse.org/package/view_file/home:jsmeix/gutenprint53t/gutenprint53t.spec?expand=1

As far as I see from the build log -ffloat-store is actually used
during compile:
https://build.opensuse.org/public/build/home:jsmeix/openSUSE_Tumbleweed/i586/gutenprint53t/_log

In
https://build.opensuse.org/project/show/home:jsmeix
I made a separated gutenprint53-testing Package
with much reduced set of PPDs that get tested
and its build log for openSUSE_Tumbleweed i586
shows basically same failures:
https://build.opensuse.org/public/build/home:jsmeix/openSUSE_Tumbleweed/i586/gutenprint53-testing/_log


I am not a C expert and even less an expert in the details
of using float data types in C.

 From my own experience about 30 years ago I remember
that in practice
"there is no such thing as 'equal' with float data types".

I.e. code that is based on 'float1 == float2' cannot work
reliably in general because even if float1 and float2
must me mathematically identical it does not mean their
representations as a limited sequences of bits are same.

This is because e.g. the least significant bits could get
arbitrarily different because of truncating/rounding during
different calculations for float1 versus float2 compared
to mathematically exact values and other things like that.

E.g. you may have a look at

https://stackoverflow.com/questions/16839658/printf-width-specifier-to-maintain-precision-of-floating-point-value/19897395

So what I did about 30 years ago was to implement my own
specific fuzzy comparisons for the precision that I need
like instead of 'float1 == float2' I used something like
fuzzy_float_equal( float1, float2 )
or instead of 'float1 < float2' I used something like
fuzzy_float_less_than( float1, float2 )
and so on.

I don't know if nowadays IEEE standards could help to avoid
that one had to implement such awkward things - i.e. help
to get what is mathematically right also with float data types.


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

Re: [Gimp-print-devel] Hp Photosmart 8150 driver for Mac Big Sur

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

> On Sep 5, 2021, at 6:57 PM, Joe Mello <joe...@gm...> wrote:
> 
> Is there a driver for HP Photosmart 8150 for Mac Big Sur?

This printer is listed should work with a PCL 3 driver. You could try the HP Deskjet 916.  This uses the pcl-900 driver.  openprinting.org indicates HP Photosmart 8000 should work with this driver.  The duplexer will not work however.

Please let us know whether it works or not.  If it does, can add it to the list.  It would also be helpful to know if there are any functions not supported.

Matt 

Re: [Gimp-print-devel] HP D110 Driver compatible with Big Sur

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

> On Sep 2, 2021, at 2:10 AM, silvia grossmann <pan...@gm...> wrote:
> 
> Hi there, 
> 
> First of all thank you so much for filling in the gap intentionally created by companies committed to the obsolescence of their products!
> 
> At this time of ecological crisis, it is outrageous that companies continue, untrammeled, to make their well-functioning products obsolete by way of not providing driver updates. I commend you on your initiative.
> 
> Could you *please* develop or point me to a driver for the HP Photosmart D-110 that is compatible with Mac OS Big Sur 11.5.2? Is there any existing resource you are aware of? 
> 
> If not what can be done so a driver is created by your brilliant folks at Gutenprint?
> 
> Please drop me a line when you have a chance.

Unfortunately, Gutenprint does not support this printer.  It needs a PCL 3 GUI driver which Gutenprint does not support.

Matt

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[Robert K. <rl...@al...>]

On 9/5/21 7:26 PM, Solomon Peachy wrote:
> On Sun, Sep 05, 2021 at 06:16:10PM -0400, Robert Krawitz wrote:
>> Sigh...have to figure out how to fix this.  Maybe we have to allow 
>> something like a millipoint of slop.  Interesting that it seems to 
>> have only hit the dyesub printers; is the issue that those are the 
>> only ones with non-integer widths (in points)?
> 
> Yeah, I can't speak for every other family but inside the dyesub driver, 
> all dimensions are specified in terms of pixels, but converted to points 
> for external consumption.
> 
> I think it's reasonable to truncate anything smaller than a millipoint, 
> though just patching that failing test to allow for a little slop seems 
> like a bandaid when there very may well be other related lurking issues that
> are ultimately due to a platform-specific FP semantics problem.

I don't want to patch the test.

> So I question whether Gutenprint is relevant for a >20-year-old 
> Pentium3-era PC -- and this OpenSUSE build is actually targeting even 
> older Pentium1-era systems that a $5 Raspberry Pi Zero would easily run 
> circles around.
> 
> Perhaps the correct thing to do is force these older targets to use 
> "correct" IEEE754 FP math through some extra GCC flags (-ffloat-store 
> might be sufficient), which would hurt performance (on an already 
> relatively glacial platform) but would mean we'd not need to make 
> otherwise unnecessary algorithmic spelunking..

I agree.  It's exactly the kind of change that might break something else.  I want to fix the
problem, but it's more important not to break existing platforms.

>   https://gcc.gnu.org/wiki/x87note
>   https://gcc.gnu.org/wiki/FloatingPointMath

Johannes, could you try that suggestion?  If it works, we'll look into how to make the change if we
safely can.

[Gimp-print-devel] Hp Photosmart 8150 driver for Mac Big Sur

[Joe M. <joe...@gm...>]

Is there a driver for HP Photosmart 8150 for Mac Big Sur?

Joe Mello

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

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

On Sun, Sep 05, 2021 at 06:16:10PM -0400, Robert Krawitz wrote:
> Sigh...have to figure out how to fix this.  Maybe we have to allow 
> something like a millipoint of slop.  Interesting that it seems to 
> have only hit the dyesub printers; is the issue that those are the 
> only ones with non-integer widths (in points)?

Yeah, I can't speak for every other family but inside the dyesub driver, 
all dimensions are specified in terms of pixels, but converted to points 
for external consumption.

I think it's reasonable to truncate anything smaller than a millipoint, 
though just patching that failing test to allow for a little slop seems 
like a bandaid when there very may well be other related lurking issues that
are ultimately due to a platform-specific FP semantics problem.

So I question whether Gutenprint is relevant for a >20-year-old 
Pentium3-era PC -- and this OpenSUSE build is actually targeting even 
older Pentium1-era systems that a $5 Raspberry Pi Zero would easily run 
circles around.

Perhaps the correct thing to do is force these older targets to use 
"correct" IEEE754 FP math through some extra GCC flags (-ffloat-store 
might be sufficient), which would hurt performance (on an already 
relatively glacial platform) but would mean we'd not need to make 
otherwise unnecessary algorithmic spelunking..

  https://gcc.gnu.org/wiki/x87note
  https://gcc.gnu.org/wiki/FloatingPointMath

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[Robert K. <rl...@al...>]

On 9/4/21 12:50 PM, Solomon Peachy wrote:
> On Sat, Sep 04, 2021 at 10:03:33AM -0400, Robert Krawitz wrote:
>>> Only on 32-bit (i586) the cupsfilter command fails for the PPDs
>>> listed below with output excerpts from the full test log file.
> 
>> All of these are dyesub printers, which might or might not be the issue.
> 
> What these printers share in common is non-printable margins that must 
> be present in the data stream (eg the imageable area is 1844 pixels wide 
> but the printer requires 1920 pixels to be sent per row) and that is 
> represented by page margins.
> 
> In this case it sounds like we're getting hit with behavioral 
> (rounding?) differences between x87 and SSE2 floating point.

Sigh...have to figure out how to fix this.  Maybe we have to allow something like a millipoint of
slop.  Interesting that it seems to have only hit the dyesub printers; is the issue that those are
the only ones with non-integer widths (in points)?

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

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

On Sat, Sep 04, 2021 at 10:03:33AM -0400, Robert Krawitz wrote:
> > Only on 32-bit (i586) the cupsfilter command fails for the PPDs
> > listed below with output excerpts from the full test log file.

> All of these are dyesub printers, which might or might not be the issue.

What these printers share in common is non-printable margins that must 
be present in the data stream (eg the imageable area is 1844 pixels wide 
but the printer requires 1920 pixels to be sent per row) and that is 
represented by page margins.

In this case it sounds like we're getting hit with behavioral 
(rounding?) differences between x87 and SSE2 floating point.

Here's a representative example from the full log:

[10846s] INFO: pdftopdf (PID 1693) started.
[10846s] INFO: gstoraster (PID 1694) started.
[10846s] INFO: rastertogutenprint.5.3 (PID 1695) started.
[10846s] DEBUG: OUTFORMAT="<none>", so output format will be CUPS/PWG Raster
[10846s] DEBUG: pdftopdf: Last filter determined by the PPD: rastertogutenprint.5.3; FINAL_CONTENT_TYPE: application/vnd.cups-raster => pdftopdf will not log pages in page_log.
[10846s] DEBUG: PDF interactive form and annotation flattening done via QPDF
[10846s] INFO: pdftopdf (PID 1693) exited with no errors.
[10846s] DEBUG: Color Manager: Calibration Mode/Off
[10846s] INFO: Color Manager: no profiles specified in PPD
[10846s] DEBUG: Color Manager: ICC Profile: None
[10846s] DEBUG: Ghostscript using Any-Part-of-Pixel method to fill paths.
[10846s] DEBUG: Ghostscript command line: gs -dQUIET -dSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -sMediaType=Glossy -r301x301 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=864 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsCompression=1 -scupsPageSizeName=w612h864 -I/usr/share/cups/fonts -c '<</.HWMargins[18.179001 72.000000 18.179993 72.000000] /Margins[0 0]>>setpagedevice' -f -_
[10846s] DEBUG: envp[0]="<CFProcessPath>"
[10846s] DEBUG: envp[1]="CONTENT_TYPE=application/pdf"
[10846s] DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
[10846s] DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
[10846s] DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
[10846s] DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
[10846s] DEBUG: envp[6]="LANG=C.UTF8"
[10846s] DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin"
[10846s] DEBUG: envp[8]="PPD=/usr/share/cups/model/gutenprint/5.3/C/stp-kodak-1400.5.3.ppd.gz"
[10846s] DEBUG: envp[9]="PRINTER_INFO=cupsfilter"
[10846s] DEBUG: envp[10]="PRINTER_LOCATION=Unknown"
[10846s] DEBUG: envp[11]="PRINTER=cupsfilter"
[10846s] DEBUG: envp[12]="RIP_MAX_CACHE=128m"
[10846s] DEBUG: envp[13]="USER=abuild"
[10846s] DEBUG: envp[14]="CHARSET=utf-8"
[10846s] DEBUG: envp[15]="FINAL_CONTENT_TYPE=application/vnd.cups-raster"
[10846s] DEBUG: Gutenprint: ================ Printing page 1      ================
[10846s] PAGE: 1 1
[10846s] DEBUG: Gutenprint: Initialize page
[10846s] DEBUG: Gutenprint:   Set special string ChannelBitDepth to 8
[10846s] DEBUG: Gutenprint:   Set special string PrintingMode to Color
[10846s] DEBUG: Gutenprint:   Set special string InputImageType to RGB
[10846s] DEBUG: Gutenprint:   Set special parameter Resolution to choice 0 (301x301)
[10846s] DEBUG: Gutenprint:   Clear special parameter Quality
[10846s] DEBUG: Gutenprint:   Set special string MediaType to Glossy
[10846s] DEBUG: Gutenprint:   PageSize = 612x792
[10846s] DEBUG: Gutenprint:   Using page size w612h864 with (792, 612)
[10846s] DEBUG: Gutenprint:   Set special string PageSize to w612h864
[10846s] DEBUG: Gutenprint:   Set special string JobMode to Job
[10846s] DEBUG: Gutenprint:   Validating options
[10846s] DEBUG: Gutenprint:     Clearing string InputSlot ((null))
[10846s] DEBUG: Gutenprint:     Clearing string Duplex ((null))
[10846s] DEBUG: Gutenprint:     Clearing string STPIOutputType ((null))
[10846s] DEBUG: Gutenprint:     Setting default string STPIOutputType to (null)
[10846s] DEBUG: Gutenprint:     Clearing string Quality ((null))
[10846s] DEBUG: Gutenprint:   Done validating options
[10846s] DEBUG: Gutenprint:   limits w 612.359 l 18.179 r 594.179  h 864.000 t 72.000 b 792.000
[10846s] DEBUG: Gutenprint:   max limits l 18.179 r 594.179 t 72.000 b 792.000
[10846s] DEBUG: Gutenprint:   Adjusting left margin from 18.179 to 18.179
[10846s] DEBUG: Gutenprint:   Adjusting right margin from 594.179 to 594.179
[10846s] DEBUG: Gutenprint:   Adjusting top margin from 72.000 to 72.000
[10846s] DEBUG: Gutenprint:   Adjusting bottom margin from 792.000 to 792.000
[10846s] DEBUG: Gutenprint:   CUPS settings w 2408 l 75 r 75  h 3010 t 301 b 301
[10846s] DEBUG: Gutenprint:        adjusted w 2408 h 3010
[10846s] DEBUG: Gutenprint: End initialize page
[10846s] DEBUG: Gutenprint: Interim page settings:
[10846s] DEBUG: Gutenprint: === BEGIN GUTENPRINT SETTINGS ===
[10846s] DEBUG: Gutenprint:     Driver: kodak-1400
[10846s] DEBUG: Gutenprint:     L: 18.179402  T: 72.000000  W: 576.000000  H: 720.000000
[10846s] DEBUG: Gutenprint:     Page: 612.358804x864.000000
[10846s] DEBUG: Gutenprint:     Conversion: traditional
[10846s] DEBUG: Gutenprint:         (PageSize) (2) (String) [w612h864]
[10846s] DEBUG: Gutenprint:         (MediaType) (2) (String) [Glossy]
[10846s] DEBUG: Gutenprint:         (Resolution) (2) (String) [301x301]
[10846s] DEBUG: Gutenprint:         (InkType) (2) (String) [RGB]
[10846s] DEBUG: Gutenprint:         (Laminate) (2) (String) [Coated]
[10846s] DEBUG: Gutenprint:         (PrintingMode) (2) (String) [Color]
[10846s] DEBUG: Gutenprint:         (ColorCorrection) (2) (String) [None]
[10846s] DEBUG: Gutenprint:         (ChannelBitDepth) (2) (String) [8]
[10846s] DEBUG: Gutenprint:         (InputImageType) (2) (String) [RGB]
[10846s] DEBUG: Gutenprint:         (ImageType) (2) (String) [TextGraphics]
[10846s] DEBUG: Gutenprint:         (JobMode) (2) (String) [Job]
[10846s] DEBUG: Gutenprint:         (STPIRawChannels) (2) (Int) [1]
[10846s] DEBUG: Gutenprint:         (PageNumber) (2) (Int) [0]
[10846s] DEBUG: Gutenprint:         (NumCopies) (2) (Int) [1]
[10846s] DEBUG: Gutenprint:         (CUPSShrinkPage) (2) (Int) [1]
[10846s] DEBUG: Gutenprint:         (Borderless) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (NativeCopies) (2) (Bool) [1]
[10846s] DEBUG: Gutenprint:         (LegacyDyesubGamma) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (LinearContrast) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (Collate) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (Brightness) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint:         (Contrast) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint:         (Saturation) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint:         (AppGamma) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint: === END GUTENPRINT SETTINGS ===
[10846s] DEBUG: Gutenprint: Page data:
[10846s] DEBUG: Gutenprint:   MediaClass = ""
[10846s] DEBUG: Gutenprint:   MediaColor = ""
[10846s] DEBUG: Gutenprint:   MediaType = "Glossy"
[10846s] DEBUG: Gutenprint:   OutputType = ""
[10846s] DEBUG: Gutenprint:   AdvanceDistance = 0
[10846s] DEBUG: Gutenprint:   AdvanceMedia = 0
[10846s] DEBUG: Gutenprint:   Collate = 0
[10846s] DEBUG: Gutenprint:   CutMedia = 0
[10846s] DEBUG: Gutenprint:   Duplex = 0
[10846s] DEBUG: Gutenprint:   HWResolution = [ 301 301 ]
[10846s] DEBUG: Gutenprint:   ImagingBoundingBox = [ 0 0 612 792 ]
[10846s] DEBUG: Gutenprint:   InsertSheet = 0
[10846s] DEBUG: Gutenprint:   Jog = 0
[10846s] DEBUG: Gutenprint:   LeadingEdge = 0
[10846s] DEBUG: Gutenprint:   Margins = [ 0 0 ]
[10846s] DEBUG: Gutenprint:   ManualFeed = 0
[10846s] DEBUG: Gutenprint:   MediaPosition = 0
[10846s] DEBUG: Gutenprint:   MediaWeight = 0
[10846s] DEBUG: Gutenprint:   MirrorPrint = 0
[10846s] DEBUG: Gutenprint:   NegativePrint = 0
[10846s] DEBUG: Gutenprint:   NumCopies = 1
[10846s] DEBUG: Gutenprint:   Orientation = 0
[10846s] DEBUG: Gutenprint:   OutputFaceUp = 0
[10846s] DEBUG: Gutenprint:   PageSize = [ 612 792 ]
[10846s] DEBUG: Gutenprint:   Separations = 0
[10846s] DEBUG: Gutenprint:   TraySwitch = 0
[10846s] DEBUG: Gutenprint:   Tumble = 0
[10846s] DEBUG: Gutenprint:   cupsWidth = 2558
[10846s] DEBUG: Gutenprint:   cupsHeight = 3311
[10846s] DEBUG: Gutenprint:   cups->width = 2408
[10846s] DEBUG: Gutenprint:   cups->height = 3010
[10846s] DEBUG: Gutenprint:   cups->adjusted_width = 2408
[10846s] DEBUG: Gutenprint:   cups->adjusted_height = 3010
[10846s] DEBUG: Gutenprint:   cupsMediaType = 0
[10846s] DEBUG: Gutenprint:   cupsBitsPerColor = 8
[10846s] DEBUG: Gutenprint:   cupsBitsPerPixel = 24
[10846s] DEBUG: Gutenprint:   cupsBytesPerLine = 7674
[10846s] DEBUG: Gutenprint:   cupsColorOrder = 0
[10846s] DEBUG: Gutenprint:   cupsColorSpace = 1
[10846s] DEBUG: Gutenprint:   cupsCompression = 1
[10846s] DEBUG: Gutenprint:   cupsRowCount = 0
[10846s] DEBUG: Gutenprint:   cupsRowFeed = 0
[10846s] DEBUG: Gutenprint:   cupsRowStep = 0
[10846s] DEBUG: Gutenprint:   shrink page to fit 1
[10846s] DEBUG: Gutenprint: === BEGIN GUTENPRINT SETTINGS ===
[10846s] DEBUG: Gutenprint:     Driver: kodak-1400
[10846s] DEBUG: Gutenprint:     L: 18.179402  T: 72.000000  W: 576.000000  H: 720.000000
[10846s] DEBUG: Gutenprint:     Page: 612.358804x864.000000
[10846s] DEBUG: Gutenprint:     Conversion: traditional
[10846s] DEBUG: Gutenprint:         (PageSize) (2) (String) [w612h864]
[10846s] DEBUG: Gutenprint:         (MediaType) (2) (String) [Glossy]
[10846s] DEBUG: Gutenprint:         (Resolution) (2) (String) [301x301]
[10846s] DEBUG: Gutenprint:         (InkType) (2) (String) [RGB]
[10846s] DEBUG: Gutenprint:         (Laminate) (2) (String) [Coated]
[10846s] DEBUG: Gutenprint:         (PrintingMode) (2) (String) [Color]
[10846s] DEBUG: Gutenprint:         (ColorCorrection) (2) (String) [None]
[10846s] DEBUG: Gutenprint:         (ChannelBitDepth) (2) (String) [8]
[10846s] DEBUG: Gutenprint:         (InputImageType) (2) (String) [RGB]
[10846s] DEBUG: Gutenprint:         (ImageType) (2) (String) [TextGraphics]
[10846s] DEBUG: Gutenprint:         (JobMode) (2) (String) [Job]
[10846s] DEBUG: Gutenprint:         (STPIRawChannels) (2) (Int) [1]
[10846s] DEBUG: Gutenprint:         (PageNumber) (2) (Int) [0]
[10846s] DEBUG: Gutenprint:         (NumCopies) (2) (Int) [1]
[10846s] DEBUG: Gutenprint:         (CUPSShrinkPage) (2) (Int) [1]
[10846s] DEBUG: Gutenprint:         (Borderless) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (NativeCopies) (2) (Bool) [1]
[10846s] DEBUG: Gutenprint:         (LegacyDyesubGamma) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (LinearContrast) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (Collate) (2) (Bool) [0]
[10846s] DEBUG: Gutenprint:         (Brightness) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint:         (Contrast) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint:         (Saturation) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint:         (AppGamma) (2) (Double) [1.000000]
[10846s] DEBUG: Gutenprint: === END GUTENPRINT SETTINGS ===
[10846s] DEBUG: Gutenprint: End page data
[10846s] ERROR: Gutenprint: Image is too wide for the page: left margin is 18.179402, width 576.000000, right edge is 594.179402
[10846s] ERROR: Gutenprint: Print options not verified; cannot print.
[10846s] DEBUG: Gutenprint: Options failed to verify.
[10846s] DEBUG: Gutenprint: Make sure that you are using ESP Ghostscript rather
[10846s] DEBUG: Gutenprint: than GNU or AFPL Ghostscript with CUPS.
[10846s] DEBUG: Gutenprint: If this is not the cause, set LogLevel to debug to identify the problem.
[10846s] DEBUG: Gutenprint: Aborted job
[10846s] DEBUG: Gutenprint: stats 0B, 0.020u, 0.000s, 0.077el
[10846s] DEBUG: Gutenprint: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[10846s] DEBUG: Gutenprint: ============================================================

  if (stp_get_left(v) + stp_get_width(v) > right)
    {
      answer = 0;
      stp_eprintf(v, _("Image is too wide for the page: left margin is %f, width %f, right edge is %f\n"),
		  stp_get_left(v), stp_get_width(v), right);
    }

Doing the math from what's reported in the error it's a perfect match, 
which means somewhere past the sixth decimal place we're off slightly.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)

Re: [Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[Robert K. <rl...@al...>]

On 9/2/21 6:39 AM, jsmeix wrote:
> 
> Hello,
> 
> in the openSUSE build service I run an automated test
> where for each Gutenprint PPD a command like
> 
> # cupsfilter -p $PPD -e -m printer/foo -i application/pdf pdf_file
> 
> is run.
> 
> The input pdf_file is made by
> 
> # echo -e '%!\n100 200 300 400 rectstroke\nshowpage' >postscript_file
> 
> # ps2pdf postscript_file pdf_file
> 
> On my 64-bit (x86_64) laptop I get
> 
> # pdfinfo pdf_file
> Producer:       GPL Ghostscript 9.54.0
> CreationDate:   Thu Sep  2 12:12:18 2021 CEST
> ModDate:        Thu Sep  2 12:12:18 2021 CEST
> Tagged:         no
> UserProperties: no
> Suspects:       no
> Form:           none
> JavaScript:     no
> Pages:          1
> Encrypted:      no
> Page size:      612 x 792 pts (letter)
> Page rot:       0
> File size:      2249 bytes
> Optimized:      no
> PDF version:    1.4
> 
> # gs -sDEVICE=bbox -dBATCH -dNOPAUSE postscript_file 2>&1 | grep '%BoundingBox'
> %%BoundingBox: 99 199 401 601
> 
> # gs -sDEVICE=bbox -dBATCH -dNOPAUSE pdf_file 2>&1 | grep '%BoundingBox'
> %%BoundingBox: 99 199 401 601
> 
> Only on 32-bit (i586) the cupsfilter command fails for the PPDs
> listed below with output excerpts from the full test log file.
> 
> It works on 64-bit (x86_64) but I do not have a 32-bit computer
> to try out things on my own - I only have the test log file.
> 
> Perhaps my test page is really too big but I wonder
> why it works on 64-bit but only fails on 32-bit?
> 
> The full log is available at
> 
> https://build.opensuse.org/public/build/Printing/openSUSE_Tumbleweed/i586/gutenprint53-testing/_log
> 
> Failed PPDs with excerpts from the test log file:
> -----------------------------------------------------------------------
> cupsfilter failed for stp-citizen-cw-02.5.3.ppd
> with this cupsfilter stderr output:
>  Gutenprint: Image is too long for the page:
>  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

All of these are dyesub printers, which might or might not be the issue.

Can you provide the CUPS error log for at least one of these failures?

[Gimp-print-devel] Gutenprint 5.3.4: only on 32-bit failures with "Image is too long/wide for the page" for certain PPDs

[jsmeix <js...@su...>]

Hello,

in the openSUSE build service I run an automated test
where for each Gutenprint PPD a command like

# cupsfilter -p $PPD -e -m printer/foo -i application/pdf pdf_file

is run.

The input pdf_file is made by

# echo -e '%!\n100 200 300 400 rectstroke\nshowpage' >postscript_file

# ps2pdf postscript_file pdf_file

On my 64-bit (x86_64) laptop I get

# pdfinfo pdf_file
Producer:       GPL Ghostscript 9.54.0
CreationDate:   Thu Sep  2 12:12:18 2021 CEST
ModDate:        Thu Sep  2 12:12:18 2021 CEST
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      612 x 792 pts (letter)
Page rot:       0
File size:      2249 bytes
Optimized:      no
PDF version:    1.4

# gs -sDEVICE=bbox -dBATCH -dNOPAUSE postscript_file 2>&1 | grep 
'%BoundingBox'
%%BoundingBox: 99 199 401 601

# gs -sDEVICE=bbox -dBATCH -dNOPAUSE pdf_file 2>&1 | grep '%BoundingBox'
%%BoundingBox: 99 199 401 601

Only on 32-bit (i586) the cupsfilter command fails for the PPDs
listed below with output excerpts from the full test log file.

It works on 64-bit (x86_64) but I do not have a 32-bit computer
to try out things on my own - I only have the test log file.

Perhaps my test page is really too big but I wonder
why it works on 64-bit but only fails on 32-bit?

The full log is available at

https://build.opensuse.org/public/build/Printing/openSUSE_Tumbleweed/i586/gutenprint53-testing/_log

Failed PPDs with excerpts from the test log file:
-----------------------------------------------------------------------
cupsfilter failed for stp-citizen-cw-02.5.3.ppd
with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cw-02.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cx-02.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cx-02.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cx.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cx.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cy-02.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cy-02.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cy.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-cy.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-citizen-op900ii.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-dnp-ds40.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-dnp-ds40.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-dnp-ds620.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-dnp-ds620.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-dnp-dsrx1.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-dnp-dsrx1.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too long for the page:
  top margin is 44.640000, height 371.520000, bottom edge is 416.160000

cupsfilter failed for stp-kodak-1400.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 18.179402, width 576.000000, right edge is 594.179402

cupsfilter failed for stp-kodak-1400.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 18.179402, width 576.000000, right edge is 594.179402

cupsfilter failed for stp-kodak-805.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 18.179402, width 576.000000, right edge is 594.179402

cupsfilter failed for stp-kodak-805.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 18.179402, width 576.000000, right edge is 594.179402

cupsfilter failed for stp-magicard-rio-2e.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 3.600000, width 154.080000, right edge is 157.680000

cupsfilter failed for stp-magicard-rio-2e.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 3.600000, width 154.080000, right edge is 157.680000

cupsfilter failed for stp-magicard-tango-2e.5.3.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 3.600000, width 154.080000, right edge is 157.680000

cupsfilter failed for stp-magicard-tango-2e.5.3.sim.ppd
  with this cupsfilter stderr output:
  Gutenprint: Image is too wide for the page:
  left margin is 3.600000, width 154.080000, right edge is 157.680000
-----------------------------------------------------------------------


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

[Gimp-print-devel] HP D110 Driver compatible with Big Sur

[silvia g. <pan...@gm...>]

Hi there, 

First of all thank you so much for filling in the gap intentionally created by companies committed to the obsolescence of their products!

At this time of ecological crisis, it is outrageous that companies continue, untrammeled, to make their well-functioning products obsolete by way of not providing driver updates. I commend you on your initiative.

Could you *please* develop or point me to a driver for the HP Photosmart D-110 that is compatible with Mac OS Big Sur 11.5.2? Is there any existing resource you are aware of? 

If not what can be done so a driver is created by your brilliant folks at Gutenprint?

Please drop me a line when you have a chance.


Thanks,

- silvia

Re: [Gimp-print-devel] AWESOME!!!! made my HP Laserjet live again!!!!

[Robert K. <rl...@al...>]

On 8/25/21 10:13 AM, Matthew McCormick via Gimp-print-devel wrote:
> Is there a way to contribute financially?  You rock!!!!!  I had tried EVERYTHING else.

Hi,

Very glad we could be of assistance.

We are not an organization and have no way to receive contributions.  If you wish, I suggest that
you make a donation to the charity of your choice.  Thanks!

[Gimp-print-devel] AWESOME!!!! made my HP Laserjet live again!!!!

[Matthew M. <mat...@ya...>]

Is there a way to contribute financially?  You rock!!!!!  I had tried 
EVERYTHING else.
-- 
Matthew McCormick Madison, WI