gimp-print-devel

[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

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Sun, Aug 15, 2021 at 09:31:46PM -0400, Robert Krawitz wrote:
> Device Drivers Are Ugly (tm)

That's practically the caption of my career.  :D

> As ugly as it is, I'd say either come up with a new integer parameter 
> for this or add an escape hatch remote sequence per-paper that you can 
> set for the papers for this printer.

I ended up doing the former.  Lacking a better name I just defined it as 
an internal parameter:

  PARAMETER_INT(roll_lb)

Which is only referenced in escp2_set_remote_sequence():

      if (stp_check_int_parameter(pv, "escp2_roll_lb", STP_PARAMETER_ACTIVE))
       stp_send_command(v, "LB", "bccc", 0, 1,
                        stp_get_int_parameter(pv, "escp2_roll_lb"));

And in the paper definition:

  <parameter type="integer" name="escp2_roll_lb">0x32</parameter>

It seems to work okay.

 - 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] Advice on how to add the Epson SL-D700

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

On 8/15/21 8:58 PM, Solomon Peachy wrote:
> On Mon, Aug 02, 2021 at 07:36:10PM -0400, Solomon Peachy wrote:
>>    LB 03 00  00 01 01           # sent before FP
> 
> It turns out this changes based on the media type.
> 
>  Glossy: 00 01 00
>  Luster: 00 01 01
>  Matte:  00 01 32
> 
> I currently have this specified in the model.xml's preInitRemoteSequence 
> but that obviously won't do. 
> 
> I've been trying to add it as a parameter from within a <paper> definition:
> 
>    <parameter type="raw" name="escp2_preinit_remote_sequence">LB\003\000\000\001\001</parameter>
> 
> But it seems pd->preinit_remote_sequence is set in setup_basic(), far 
> before the paper definition is parsed. I added a hack in 
> adjust_density_and_ink_type() to explicitly check for that parameter:
> 
>   if (pv && stp_check_raw_parameter(pv, "escp2_preinit_remote_sequence", STP_PARAMETER_ACTIVE))
>     pd->preinit_remote_sequence = escp2_preinit_remote_sequence(pv);
> 
> but that's a pretty ugly hack IMO. It perhaps makes more sense to add a 
> generic LB command send into escp2_set_remote_sequence() and create a 
> parameter to configure it.  But what should I call it?

Device Drivers Are Ugly (tm)

There are already a bunch of special cases for papers starting at line 289 of print-escp2-data.c.
On the one hand, I hate adding yet one more.  On the other, I don't really want to restructure the
XML data for every existing printer and paper, and it would be a lot of work to rework all of the
existing PaperThickness/FeedSequence/PlatenGap options (there are 566 as it stands), and converting
them to fixed remote mode strings would reduce flexibility for people who want to tune them for
funky media of their own.

As ugly as it is, I'd say either come up with a new integer parameter for this or add an escape
hatch remote sequence per-paper that you can set for the papers for this printer.

Re: [Gimp-print-devel] Advice on how to add the Epson SL-D700

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

On Mon, Aug 02, 2021 at 07:36:10PM -0400, Solomon Peachy wrote:
>    LB 03 00  00 01 01           # sent before FP

It turns out this changes based on the media type.

 Glossy: 00 01 00
 Luster: 00 01 01
 Matte:  00 01 32

I currently have this specified in the model.xml's preInitRemoteSequence 
but that obviously won't do. 

I've been trying to add it as a parameter from within a <paper> definition:

   <parameter type="raw" name="escp2_preinit_remote_sequence">LB\003\000\000\001\001</parameter>

But it seems pd->preinit_remote_sequence is set in setup_basic(), far 
before the paper definition is parsed. I added a hack in 
adjust_density_and_ink_type() to explicitly check for that parameter:

  if (pv && stp_check_raw_parameter(pv, "escp2_preinit_remote_sequence", STP_PARAMETER_ACTIVE))
    pd->preinit_remote_sequence = escp2_preinit_remote_sequence(pv);

but that's a pretty ugly hack IMO. It perhaps makes more sense to add a 
generic LB command send into escp2_set_remote_sequence() and create a 
parameter to configure it.  But what should I call it?

 - 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] Drivers for a Cannon i9900 to use on Big Sur

[Steve L. <sle...@ya...>]

If this is an Intel Chip based Mac the current Mac version will work. If it is a Silicon based Mac, we should have a version out for you in about a week. 

You can determine which Mac you have by simply picking “About this Mac” under the Apple menu. A silicon will state it has an Apple M1 chip, Intel will state it has an Intel chip. 

Steve Letter
Sent from my Symbolics Lisp Machine using zmail. 

> On Aug 11, 2021, at 7:56 PM, Kenneth Leach via Gimp-print-devel <gim...@li...> wrote:
> 
> Hello
> 
> I recently lost the hard drive and mother board in my older Mac and replaced it with a new iMac.  The new computer uses Big Sur  and now I can’t use my Cannon i9900 printer.  On your web site it says that you might have experimental drivers for the i9900 but it doesn’t say if they might work on Big Sur.  I love that printer and am really hoping you might be able to help me out with drivers.  
> 
> Thank you.
> 
> Ken Leach.       Ken_lin_leach@q.com
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Drivers for a Cannon i9900 to use on Big Sur

[Gernot H. <aik...@gm...>]

On Thu, Aug 12, 2021 at 8:56 AM Kenneth Leach via Gimp-print-devel
<gim...@li...> wrote:
>
> Hello
>
> I recently lost the hard drive and mother board in my older Mac and replaced it with a new iMac.  The new computer uses Big Sur  and now I can’t use my Cannon i9900 printer.  On your web site it says that you might have experimental drivers for the i9900 but it doesn’t say if they might work on Big Sur.  I love that printer and am really hoping you might be able to help me out with drivers.

Hello Ken,
If gutenprint can install on your MacOSX version then the i9900 should
work as far as it is capable.
Best regards,
Gernot Hassenpflug

> Thank you.
>
> Ken Leach.       Ken_lin_leach@q.com
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel



-- 
Protea Wines Japan
Tel: 070-5550-9076
https://www.proteawines.jp

[Gimp-print-devel] Drivers for a Cannon i9900 to use on Big Sur

[Kenneth L. <ken...@me...>]

Hello

I recently lost the hard drive and mother board in my older Mac and replaced it with a new iMac.  The new computer uses Big Sur  and now I can’t use my Cannon i9900 printer.  On your web site it says that you might have experimental drivers for the i9900 but it doesn’t say if they might work on Big Sur.  I love that printer and am really hoping you might be able to help me out with drivers.  

Thank you.

Ken Leach.       Ken_lin_leach@q.com

Re: [Gimp-print-devel] RFC: hacks to get the SureLab D700 working

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

On Tue, Aug 10, 2021 at 08:30:52PM -0400, Robert Krawitz wrote:
> That's what I would do here.

Ok, it's done and pushed, including a blurb in the esc/p2 documentation 
about that ESC(g command.

All that now remains for D700 support are the WIP XML files.

Do you see any value in committing the current state of affairs or 
should I hold off until after things are tuned somewhat better?

> Don't do that without doing a full before/after comparison with every 
> printer via make checksums in src/testpattern.  It generates this 
> radically compressed output (sometimes it needs less than bits per 
> test case!) that can be compared via compare-checksums.  I don't 
> remember why I had to special case 720x360, but there was some old 
> printer that needed this.

I'd expect it to cause changes in output for many other models, so I 
didn't even consider doing that -- but what I could do is special-case 
the special-case so it only kicks in if it's not a roll-only model?

 - 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] Advice on how to add the Epson SL-D700

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

On 8/10/21 8:43 PM, Solomon Peachy wrote:
> On Tue, Aug 10, 2021 at 08:23:20PM -0400, Robert Krawitz wrote:
>> You might instead want to specify it in terms of the base unit (14400 on most printers)
> 
> That would be 'resolutionScale' in the model.xml file?
> 
> FWIW I went with baseSeparation units because initialVerticalOffset and 
> blackVerticalOffset were already in baseSeparation units.

That makes sense.

>> When you tune drop sizes, you don't want to tune them at anywhere near saturation, because
>> overlapping dots result in non-linear response.  I usually tune them somewhere around 25% IIRC.  For
> 
> Yeah, I'd managed to dial it back to where pure CYMK colors looked 
> pretty good but when two inks had to mix (especially Y+C=G) it was 
> actually puddling on the paper..

Yep, you're going to need to back off from there.

>> light inks, it's very important not to be saturated.  You might want 
>> to tune those at the smallest possible drop size so you have the least 
>> speckling.
> 
> Any advice on how to deliberately generate the smallest drop sizes?

Modify (temporarily) the drop sizes to only include the smallest size.

>> I wish I could say I have a more scientific procedure, but not really.
> 
> Ok, glad to hear I'm not making this unnecessary complicated for myself.

I probably should have tried to make it easier.