gimp-print-devel

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

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

Gutenprint 5.3.5-pre1 is a prerelease of Gutenprint 5.3.5.  

It may be downloaded from our web site, 
https://gutenprint.sourceforge.net. The direct download is 
https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.5-pre1/gutenprint-5.3.5-pre1.tar.xz/download

Gutenprint is a suite of printer drivers for Linux and UNIX-like systems 
that use CUPS as their printing system.  Gutenprint currently supports 
over 3600 printers.  It also includes an enhanced Print plug-in for 
GIMP that replaces the print plug-in packaged with the GIMP 
distribution.

Gutenprint 5.3.5-pre1 is only distributed in source form; third parties 
(such as Linux distriutions) typically prepare and distribute binaries 
for their systems.

This pre-release is the first non-snapshot build in several years, and 
primarily acts a roundup of the various additions and fixes that have 
accumulated since the 5.3.4 release.  Additionally, this prerelease is 
intended to help familiarize the current Gutenprint maintainer with the 
release flow.

Please report any problems to gim...@li....  

Notable changes from 5.3.4:

  0) Support for running on MacOS has been deprecated. Unless someone
     steps up to maintain the MacOS port, there will be no MacOS
     builds for this (or any future) Gutenprint release.

  1) Support for the following Dye-sublimation & thermal printers
     has been added:

     Canon SELPHY CP1500
     DNP DS480
     DNP DS680
     HiTi P461 Prinhome
     HiTi P510K / P510L / P510S / P510SI
     HiTi P518A / P518S (EXPERIMENTAL)
     HiTi P728L (EXPERIMENTAL)
     Mitsubishi CP-W5000 series
     Olmec OP1000
     Sony UP-CX1
     Sont UP-D711MD
     Sony UP-971AD
     Sony UP-991AD (EXPERIMENTAL)

  2) The following printers have received significant bugfixes or
     major enhancements:

     Canon SELPHY CP790
     DNP DS620
     DNP DS820
     Fujifilm ASK-2500
     HiTi P520L
     HiTi P525L
     HiTi P720L
     HiTi P750L (EXPERIMENTAL)
     Kodak 605
     Kodak 8800 / 9810
     Kodak 8810
     Mitsubishi CP-D70/D707 series
     Mitsubishi CP-K60 series
     Mitsubishi CP-M1 & CP-M15 series
     Nidec Copal DPB-7000

  3) Added CUPS Command filter support for most dyesub models.  This allows
     querying printer status and media information at any time.

  4) Added support for the following inkjet printer models:

     Epson SureLab D700
     Fujifilm DX100

  5) Added support for the following laser printer models:

     Sharp MX-2600N

  6) Various minor fixes and enhancements

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

Re: [Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

[Walker B. <fo...@wa...>]

I can follow 60% of this . . .

If I were to force it to print the basic CMYK percentages (basically nix all the GCR combo stuff and print 40% black if that is what the pixel has for its K value no matter what)

I see that I can just say output[0] = k;

But I don’t follow the logic of ck * cg.

Maybe ideally I’m simply saying for the color outputs that it’s 1 * cg->color_balance. ?

Would this output a more dumbed down thing?

best
-Walker




> On Jul 1, 2024, at 1:24 PM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Mon, Jul 01, 2024 at 11:17:40AM -0400, Walker Blackwell wrote:
>> There is some multiplication of numbers between the CMYK channels that 
>> is happening in the system at some point. Does anyone know what this 
>> multiplication is? If it’s a standard number/thing I can apply it to 
>> my backwards math.
> 
> Coincidentally, I think I ran into what you're looking for last week. 
> Have a look at do_gcr() in src/main/channels.c:
> 
> This is its main loop:
> 
>  for (i = 0; i < cg->width; i++)  // ie repeat for each pixel
>    {
>      unsigned k = output[0];
>      if (k > 0)
> 	{
> 	  int kk = gcr_lookup[k];
> 	  int ck;
> 	  if (kk > k)
> 	    kk = k;
> 	  ck = k - kk;
> 	  output[0] = kk;
> 	  output[1] += ck * cg->cyan_balance;
> 	  output[2] += ck * cg->magenta_balance;
> 	  output[3] += ck * cg->yellow_balance;
> 	  nzx.nzl |= *(unsigned long long *) output;
> 	}
>      output += cg->gcr_channels;
>    }
> 
> 
> 
> - Solomon
> -- 
> Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
>                                      @pizza:shaftnet dot org   (matrix)
> Dowling Park, FL                      speachy (libera.chat)
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

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

On Mon, Jul 01, 2024 at 11:17:40AM -0400, Walker Blackwell wrote:
> There is some multiplication of numbers between the CMYK channels that 
> is happening in the system at some point. Does anyone know what this 
> multiplication is? If it’s a standard number/thing I can apply it to 
> my backwards math.

Coincidentally, I think I ran into what you're looking for last week. 
Have a look at do_gcr() in src/main/channels.c:

This is its main loop:

  for (i = 0; i < cg->width; i++)  // ie repeat for each pixel
    {
      unsigned k = output[0];
      if (k > 0)
	{
	  int kk = gcr_lookup[k];
	  int ck;
	  if (kk > k)
	    kk = k;
	  ck = k - kk;
	  output[0] = kk;
	  output[1] += ck * cg->cyan_balance;
	  output[2] += ck * cg->magenta_balance;
	  output[3] += ck * cg->yellow_balance;
	  nzx.nzl |= *(unsigned long long *) output;
	}
      output += cg->gcr_channels;
    }



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

[Gimp-print-devel] Calculating actual Ink amounts from CMYK pipeline

[Walker B. <fo...@wa...>]

Dear Gutenprint community,

I’m at it again and doing some weird monochromatic toned printing with Gutenprint on an Epson P9000.

I’ve noticed something strange. If I build a CMYK profile and print a neutral target (gray ramp) that is converted to that profile with it through CMYK ink set in Gutenprint everything is correct.

If I print the same hard-encoded CMYK target four times through the printer by printing normal density of a single color per print (cyan at 1, MYK at 0, Magenta at 1 CYK at 0, etc) the print is entirely different with not enough black ink and too much color ink (in comparison).

There is some multiplication of numbers between the CMYK channels that is happening in the system at some point. Does anyone know what this multiplication is? If it’s a standard number/thing I can apply it to my backwards math.

warmest,
-Walker

[Gimp-print-devel] Brother MFC 9142 CDN

[Klaus-Dieter S. <kd...@se...>]

Hallo,
Ich suche dringend einen Treiber für Brother MFC 9142 CDN unter MAC OSX 15.5


Mit freundlichen Grüßen
Klaus-Dieter Seeber


************************************
Dipl.-Ing. oec. Klaus-Dieter Seeber
98694 Ilmenau OT Gehren/Thüringen
Großbreitenbacher Straße 39

DL6KDS

FON : +49 36783 87900
FAX : +49 36783 87901
MOBILE : +49 171 5300907
e-Mail : kd...@se...
************************************

[Gimp-print-devel] Decrease nozzles lead to the appearance of light stripes.

[Andrew X <68...@gm...>]

Hello!
I understand that I use gutenprint not in a very usual way, but hope for
your help!

I use it with epson xp15000 (6ch x 180nozzles) in bidirection mode.
When i modify xml and set 90 nozzles -
Light stripes start to appear on the image.

It looks as if, when the head moves in one direction, it dispenses less ink
than when moving in the other direction.

With unidirectional printing, this effect disappears.

To some extent, this occurs with all available rasterization algorithms.
But if you set it to 180 nozzles, everything becomes fine.


Perhaps you know what might be the issue or in which direction I should
look to find a solution to this problem?

[Gimp-print-devel] 12265 Mt. Hamilton Rd.-RFI 1

[CESAR O. <exc...@ao...>]

Hello-
I am the Project Manager at this project.
I have the following questions:

1) There were some piers drilled and poured on the western end of wall ‘E’.
Did you review and approve the work? Were they Inspected by the City?

2) Above and behind the Guest House and the Garage there are small retaining walls shown to be block retaining walls. Owners indicate that the walls are no longer to be block walls but poured in place retaining walls supported on piers. However, no further details were made available. 
Do you have direction as to what details to follow? Or do you have new details?

3) At the driveway outfall structure (8a/c15) an outlet invert is given that is 3’ below the BW. I assume then that the structure itself projects through the RW spread footing. If so, please provide direction as to how to accommodate the rebar necessary to bridge around the structure and also how to isolate the spread footing from the structure itself and provide waterproofing at the joint.

4) We are interested in substituting the concrete structures in the drainage system to plastic utilizing ADS products. Would you be amenable to to the idea?

I look forward to your response-
Cesar Olmos
Project Manager
408-309-2886 text

[Gimp-print-devel] CI runs failing &| snapshots not being uploaded?

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

I've been trying to figure out why no new snapshots have been uploaded 
to the sourceforge, but travis-ci seems to no longer know about 
gutenprint; at least not at the URLs tossed about when it was being set 
up.

So, (1) Does it still live, and if so, (2) can I get access to it?

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

Re: [Gimp-print-devel] Advice Needed: Develop Driver Epson SureColor P-5000

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

On Wed, Jan 03, 2024 at 11:17:42AM -0500, Bacon At Taha wrote:
> Thank you very much Solomon! That is very helpful information to get me started.
> 
> When the time comes, what is the procedure for submitting patches? I have experience using github this way, but not SourceForge.

Sourceforge has a ticketing system, and the ability to fork and submit 
pull requests.  Or you can post a patch to the mailing list.

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

Re: [Gimp-print-devel] Advice Needed: Develop Driver Epson SureColor P-5000

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

Thank you very much Solomon! That is very helpful information to get me started.

When the time comes, what is the procedure for submitting patches? I have experience using github this way, but not SourceForge.


Regards,

Erik

Sent from my iPhone

> On Jan 3, 2024, at 11:08, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Sun, Dec 31, 2023 at 04:31:43PM -0500, Erik Beck wrote:
>> I have an Epson SureColor P-5000 (commercial edition), a 10 ink 17"
>> wide-format printer. I am currently printing to it either in Linux via
>> an Epson PPD for device, or via Windows.  I would like to be able to
>> support it properly with gutenprint. What's the best way to develop a
>> driver based on the existing SureColor drivers (P-6000, P-7000, etc)?
> 
> Hmm.  I'm far from an expert when it comes to the Epson Inkjets.  But
> assuming it's just a size variant of the P6000/P7000 models and still
> supports ESC/P2 (as opposed to ESC/PR) then a good place to start is to
> generate a raw data dump (eg print-to-file under Windows) andpass that
> into parse-escp2 to see what's going on.
> 
> (To determine the PDLs it suppors, plug the printer into a Linux box and run
> 'lpinfo -lv' and look at the 'device-id' string.  Of particular interest
> is the 'CMD:....' string)
> 
> Meanwhile, A good example of what's needed to add a new epson printer is
> commit 97efe256b, which added support for the SL-D700 (a bespoke 6-ink
> set and printer-specific roll-only paper types).
> 
> But it's more likely that you can largely cut-n-paste the definition of
> the P7000CE in srx/xml/printers/escp2.xml with a unique modelid, then
> copy src/xml/escp2/models/model_126.xml to the new modelid, and modify
> it to change the imageable area.
> 
> If the P5000CE uses a new inkset, you'll need to create a new one (again
> you can use the definition referenced in the model_126 file as an
> example).   
> 
> So that's a decent starting point.
> 
> - Solomon
> --
> Solomon Peachy                  pizza at shaftnet dot org (email&xmpp)
>                                      @pizza:shaftnet dot org   (matrix)
> Dowling Park, FL                      speachy (libera.chat)
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Advice Needed: Develop Driver Epson SureColor P-5000

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

On Sun, Dec 31, 2023 at 04:31:43PM -0500, Erik Beck wrote:
> I have an Epson SureColor P-5000 (commercial edition), a 10 ink 17"
> wide-format printer. I am currently printing to it either in Linux via
> an Epson PPD for device, or via Windows.  I would like to be able to
> support it properly with gutenprint. What's the best way to develop a
> driver based on the existing SureColor drivers (P-6000, P-7000, etc)?

Hmm.  I'm far from an expert when it comes to the Epson Inkjets.  But 
assuming it's just a size variant of the P6000/P7000 models and still 
supports ESC/P2 (as opposed to ESC/PR) then a good place to start is to 
generate a raw data dump (eg print-to-file under Windows) andpass that 
into parse-escp2 to see what's going on.

(To determine the PDLs it suppors, plug the printer into a Linux box and run 
 'lpinfo -lv' and look at the 'device-id' string.  Of particular interest 
 is the 'CMD:....' string)

Meanwhile, A good example of what's needed to add a new epson printer is 
commit 97efe256b, which added support for the SL-D700 (a bespoke 6-ink 
set and printer-specific roll-only paper types).

But it's more likely that you can largely cut-n-paste the definition of 
the P7000CE in srx/xml/printers/escp2.xml with a unique modelid, then 
copy src/xml/escp2/models/model_126.xml to the new modelid, and modify 
it to change the imageable area.

If the P5000CE uses a new inkset, you'll need to create a new one (again 
you can use the definition referenced in the model_126 file as an 
example).   

So that's a decent starting point.

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

[Gimp-print-devel] Advice Needed: Develop Driver Epson SureColor P-5000

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

Hi all,

I have an Epson SureColor P-5000 (commercial edition), a 10 ink 17"
wide-format printer. I am currently printing to it either in Linux via
an Epson PPD for device, or via Windows.  I would like to be able to
support it properly with gutenprint. What's the best way to develop a
driver based on the existing SureColor drivers (P-6000, P-7000, etc)?

Thanks,

Erik

[Gimp-print-devel] Faulty floating point comparisons lead to false errors

[Johannes M. <js...@su...>]

Hello,

this is a follow up of the mail thread with subject

"Gutenprint 5.3.4: only on 32-bit failures with
  'Image is too long/wide for the page'
for certain PPDs"

see

https://sourceforge.net/p/gimp-print/mailman/gimp-print-devel/thread/5676098bc0fd4489557f650e2199ebd9%40suse.de

At SUSE we did some deeper investigation of the root cause
and came to the following conclusions:

Rounding effects in intermediate calculations
throw results off by some least significant bits
with any limited-precision floating point formats.

If you do:
------------------------------------------------------
floattype a = <some calculation 1>;
floattype b = <some other calculation 2>;
------------------------------------------------------
where mathematically calc1 and calc2 are the same value,
then
------------------------------------------------------
if (a > b)   /* which imples a != b */
   error();
------------------------------------------------------
calls for unpredictable problems.

On hardware 1 it might work, on hardware 2 it might not,
when calc1 and calc2 happen to be implemented
with different sequences of CPU instructions
on hardware 1 versus hardware 2.

This cannot be properly fixed with compiler settings
because then calc1 and calc2 can still be implemented
with different sequences of CPU instructions
on hardware 1 versus hardware 2.

The only way out (for what is needed in this case)
is using an epsilon neighbourhood for comparisons
with floating point formats.

For example like the following:

With an open epsilon neighbourhood of b:
------------------------------------------------------
/* consider a greater than b
  * only if a is significantly greater than b
  */
if ( a >= b + epsilon )

/* consider a less than b
  * only if a is significantly less than b
  */
if ( a <= b - epsilon )

/* consider a equals b
  * when a and b do not significantly differ
  */
if ( a < b + epsilon && a > b - epsilon )
------------------------------------------------------
or alternatively
with a closed epsilon neighbourhood of b:
------------------------------------------------------
/* consider a greater than b
  * only if a is significantly greater than b
  */
if ( a > b + epsilon )

/* consider a less than b
  * only if a is significantly less than b
  */
if ( a < b - epsilon )

/* consider a equals b
  * when a and b do not significantly differ
  */
if ( a <= b + epsilon && a >= b - epsilon )
------------------------------------------------------

The point is to not tinker with the calculations
but to only fix the comparisons.


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Frankenstr. 146 - 90461 Nuernberg - Germany
GF: Ivo Totev, Andrew McDonald, Werner Knoblich
(HRB 36809, AG Nuernberg)

[Gimp-print-devel] ET-8550

[John D. <joh...@ya...>]

Hello,
The ET-8550 is a six-color Epson EcoTank printer.  I would like to have one set up to print carbon monochrome prints.  I am wondering if your team is looking at supporting it, or whether it is a matter of porting over other six-color programming (this is not my area of expertise, obviously).
I think a refillable B&W printer would be quite wonderful, avoiding the work-arounds needed to foil cartridge protection schemes.
Thank you.
Best Regards,
John

Re: [Gimp-print-devel] RFC: New release and abandoning MacOS?

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

> On Jun 28, 2023, at 8:19 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Wed, Jun 28, 2023 at 07:44:55PM -0500, Matt Broughton wrote:
>> I am not sure I know all of the macOS issues or how difficult it would 
>> be to accomodate them.  I do know that the v5.3.x macOS releases are a 
>> show stopper for printers that can print on CDs or DVDs. No Printer 
>> Features can be seen in the GUI.  Even trying to see the Printer 
>> Features will crash some applications. PPDs can be modified to resolve 
>> this issue.  Alternatively, genppd.c can be modified.  I have a 
>> modified genppd.c we used for testing that fixes the issue.
> 
> Since this is due to a PPD construct, I assume this problem happens with 
> remote network printers (set up to use a PPD instead of IPP) as well as 
> locally-attached ones?

I believe that is correct.

> 
> Meanwhile, what's the technical argument against merging this change?

It isn't a technical argument.  It is a feature issue.  The problem under macOS is using custom CD sizes.  That is where the user can manually enter a value in the print window that isn't contained in the spin box.  The PPD needs to have the following lines removed--

*CustomStpCDOuterDiameter True: "pop"
*ParamCustomStpCDOuterDiameter Value/Value: 1 points 184 340
 
*CustomStpCDInnerDiameter True: "pop"
*ParamCustomStpCDInnerDiameter Value/Value: 1 points 45 121
 
*CustomStpCDXAdjustment True: "pop"
*ParamCustomStpCDXAdjustment Value/Value: 1 points -30 30
 
*CustomStpCDYAdjustment True: "pop"
*ParamCustomStpCDYAdjustment Value/Value: 1 points -30 30

Implementing the change globally takes away an important feature for non-macOS users.  There was no decision on how to deal with this.  It didn't seem palatable to test for Apple platform in the source code.

Matt

Re: [Gimp-print-devel] RFC: New release and abandoning MacOS?

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

On Wed, Jun 28, 2023 at 07:44:55PM -0500, Matt Broughton wrote:
> I am not sure I know all of the macOS issues or how difficult it would 
> be to accomodate them.  I do know that the v5.3.x macOS releases are a 
> show stopper for printers that can print on CDs or DVDs. No Printer 
> Features can be seen in the GUI.  Even trying to see the Printer 
> Features will crash some applications. PPDs can be modified to resolve 
> this issue.  Alternatively, genppd.c can be modified.  I have a 
> modified genppd.c we used for testing that fixes the issue.

Since this is due to a PPD construct, I assume this problem happens with 
remote network printers (set up to use a PPD instead of IPP) as well as 
locally-attached ones?

Meanwhile, what's the technical argument against merging this change?

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

Re: [Gimp-print-devel] RFC: New release and abandoning MacOS?

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

> On Jun 27, 2023, at 12:03 PM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> I'd _really_ like to see a proper, full release go out; I'm still 
> getting bug/support issues about 5.3.3, which is the last release we 
> actually announced... nearly four years ago.  While we did cut a 5.3.4 
> tarball, we never announced it to the world, holding back due to the
> lack of a sane/working MacOS installer.
> 
> In the subequent 2.5 years, things are even worse today on the MacOS 
> front, as Apple has continuted to iterate on their platform vision in a
> way we've just not been able to keep up with.
> 
> Meanwhile, there have been more printer additions and even more 
> bugfixes, and I think it's past the time we cut a new release so maybe 
> our first answer to nearly every support request won't be "uninstall 
> whatever you got from your distro and compile Gutenprint maually"
> 
> Additionally, since we can't meaningfully support MacOS at all any more, 
> IMO it makes more sense to just walk away from it entirely.  Once we get 
> a "Gutenprint Printer Application" working for the brave new 
> IPP-Everywhere paradigm, we can revisit releasing that for MacOS if it 
> still makes sense to do so.
> 
> Thoughts?  

By all means, go forward.  Not having an active maintainer for macOS shouldn't hold up progress on other fronts. 

I am not sure I know all of the macOS issues or how difficult it would be to accomodate them.  I do know that the v5.3.x macOS releases are a show stopper for printers that can print on CDs or DVDs. No Printer Features can be seen in the GUI.  Even trying to see the Printer Features will crash some applications. PPDs can be modified to resolve this issue.  Alternatively, genppd.c can be modified.  I have a modified genppd.c we used for testing that fixes the issue.

I'm not sure what label you should put on the Mac platform.  Suspended/inactive or currently unsupported might work.  Perhaps it will generate some inquiries and lead to returning to an active maintainer status.

Matt

Re: [Gimp-print-devel] RFC: New release and abandoning MacOS?

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

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

> I'd _really_ like to see a proper, full release go out; I'm still 
> getting bug/support issues about 5.3.3, which is the last release we 
> actually announced... nearly four years ago.  While we did cut a 5.3.4 
> tarball, we never announced it to the world, holding back due to the
> lack of a sane/working MacOS installer.
>
> In the subequent 2.5 years, things are even worse today on the MacOS 
> front, as Apple has continuted to iterate on their platform vision in a
> way we've just not been able to keep up with.
>
> Meanwhile, there have been more printer additions and even more 
> bugfixes, and I think it's past the time we cut a new release so maybe 
> our first answer to nearly every support request won't be "uninstall 
> whatever you got from your distro and compile Gutenprint maually"
>
> Additionally, since we can't meaningfully support MacOS at all any more, 
> IMO it makes more sense to just walk away from it entirely.  Once we get 
> a "Gutenprint Printer Application" working for the brave new 
> IPP-Everywhere paradigm, we can revisit releasing that for MacOS if it 
> still makes sense to do so.

Speaking as a packager (pkgsrc) and user (on NetBSD), this seems
reasonable.

I am unclear on the mac issues; I wonder if a command-line build is
workable, skipping the entire GUI world, so that
e.g. pkgsrc/homebrew/fink could build it on macOS.  But if even that is
too much, just marking it unsupported (while not actively withdrawing)
makes sense.

Speaking as a Free Software community member, I think it's 100% ok to
simply decline to support a non-Free system that is becoming more
difficult.  mac users are welcome to ask Apple to contribute fixes, to
do the work themselves, or to hire someone to do it.


Separately, I remember some issues with 5.3.4 on NetBSD that I didn't
manage to figure out, so my suggestion would be to tag an alpha (with a
release tarball) as soon as reasonably practical to ask packagers and
users to start testing.

Greg

[Gimp-print-devel] RFC: New release and abandoning MacOS?

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

I'd _really_ like to see a proper, full release go out; I'm still 
getting bug/support issues about 5.3.3, which is the last release we 
actually announced... nearly four years ago.  While we did cut a 5.3.4 
tarball, we never announced it to the world, holding back due to the
lack of a sane/working MacOS installer.

In the subequent 2.5 years, things are even worse today on the MacOS 
front, as Apple has continuted to iterate on their platform vision in a
way we've just not been able to keep up with.

Meanwhile, there have been more printer additions and even more 
bugfixes, and I think it's past the time we cut a new release so maybe 
our first answer to nearly every support request won't be "uninstall 
whatever you got from your distro and compile Gutenprint maually"

Additionally, since we can't meaningfully support MacOS at all any more, 
IMO it makes more sense to just walk away from it entirely.  Once we get 
a "Gutenprint Printer Application" working for the brave new 
IPP-Everywhere paradigm, we can revisit releasing that for MacOS if it 
still makes sense to do so.

Thoughts?  

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

Re: [Gimp-print-devel] WWW updates

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

> On Jun 14, 2023, at 5:29 PM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> Sourceforge graciously notified us that they'll be updating the truly 
> ancient PHP version that has been powering the gutenprint www site, moving
> from v5.4 to v7.4 in August, and then to v8 at some point after that.
> 
> This is a good thing, but it turns out our ancient www code just wasn't 
> ready.  I just fixed up the last of those issues, and told sourceforge 
> to move our site to the PHP7 host.
> 
> Unfortunately, this meanns the base of the URLs was changed from from 
> http://gimp-print.sourceforge.net to https://gimp-print.sourceforge.io.  
> Sourceforge has a permanent redirect in place that is supposed to stay 
> there indefinitely, so that should work out ok.
> 
> I also took this opportunity to clean up the various URLs on our WWW 
> site to ensure they use https where possible.
> 
> And now, back to your previously scheduled limping along.  :)

Thank you Solomon. 
Matt 

Re: [Gimp-print-devel] WWW updates

[Russell S. <rj...@ne...>]

On 15/6/23 08:29, Solomon Peachy via Gimp-print-devel wrote:
> Sourceforge graciously notified us that they'll be updating the truly
> ancient PHP version that has been powering the gutenprint www site, moving
> from v5.4 to v7.4 in August, and then to v8 at some point after that.

Das ist gut ;)

[Gimp-print-devel] WWW updates

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

Sourceforge graciously notified us that they'll be updating the truly 
ancient PHP version that has been powering the gutenprint www site, moving
from v5.4 to v7.4 in August, and then to v8 at some point after that.

This is a good thing, but it turns out our ancient www code just wasn't 
ready.  I just fixed up the last of those issues, and told sourceforge 
to move our site to the PHP7 host.

Unfortunately, this meanns the base of the URLs was changed from from 
http://gimp-print.sourceforge.net to https://gimp-print.sourceforge.io.  
Sourceforge has a permanent redirect in place that is supposed to stay 
there indefinitely, so that should work out ok.

I also took this opportunity to clean up the various URLs on our WWW 
site to ensure they use https where possible.

And now, back to your previously scheduled limping along.  :)

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

Re: [Gimp-print-devel] Epson SC-P900 Support

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

On Fri, May 12, 2023 at 03:54:49AM +0200, Marius Steffen wrote:
> any news/progress on this?

Nothing on my end, certainly.

But as an example, when I added in the Epson SL-D700 (roll-fed, 6-color 
inkset) about two years ago, I produced over 100 6x8" prints before the 
print quality was considered "good enough" for client -- and there was 
still a lot of work remaining for the remaining quality+paper 
combinations.

Granted that included prints that I made when trying to implement basic 
functonal support, and I didn't quote know what I was doing when I 
started.  Putting aside the truly new ink colors, the more inks are 
involved (and drop sizes) the more knobs there are to tune.

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

Re: [Gimp-print-devel] Epson SC-P900 Support

[Marius S. <ma...@ma...>]

Hi,

any news/progress on this?

Kind regards,

Marius Steffen
ma...@ma...



> Am 31.03.2023 um 23:28 schrieb Marius Steffen <ma...@ma...>:
> 
> Sorry for the weird reply, I had my subscription paused, so I cannot properly reply.
> 
> I’m aware of both AirPrint and Epson driver support, but I’d love to have the additional capabilities of Gutenprint, especially manual linearization.
> How much ink are we roughly talking about? 
> 
> Greetings,
> 
> 
> Marius Steffen
> ma...@ma...
> 
> 
> 
>> Am 31.03.2023 um 00:56 schrieb Marius Steffen <ma...@ma...>:
>> 
>> Hi,
>> 
>> I’ve just got a new Epson SC-P900 and noticed there’s no support in Gutenprint for it - is there anything I can provide you with to add support for it?
>> 
>> Greetings,
>> 
>> 
>> Marius Steffen
>> ma...@ma...
>> 
>> 
>> 
> 

Re: [Gimp-print-devel] Epson SC-P900 Support

[Marius S. <ma...@ma...>]

Sorry for the weird reply, I had my subscription paused, so I cannot properly reply.

I’m aware of both AirPrint and Epson driver support, but I’d love to have the additional capabilities of Gutenprint, especially manual linearization.
How much ink are we roughly talking about? 

Greetings,


Marius Steffen
ma...@ma...



> Am 31.03.2023 um 00:56 schrieb Marius Steffen <ma...@ma...>:
> 
> Hi,
> 
> I’ve just got a new Epson SC-P900 and noticed there’s no support in Gutenprint for it - is there anything I can provide you with to add support for it?
> 
> Greetings,
> 
> 
> Marius Steffen
> ma...@ma...
> 
> 
>