gimp-print-devel

Re: [Gimp-print-devel] Gutenprint plugin for Gimp 3

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

On Sat, Mar 29, 2025 at 04:51:24PM +0100, Alain Second via Gimp-print-devel wrote:
> "An enhanced Print plug-in for the GIMP."
> What about a pritnt plugin for Gimp 3 ? When ?

Doing a GIMP3 port requires (1) porting the libgutenprintui library from 
GTK2 to GTK3, and (2) porting the actual plugin to use GEGL so fancier 
things like non-8bpp image data can be properly handled.  This 
represents a large chunk of work, even for someone who is familiar with 
GTK.

As for when, I'll quote the "future of gutenprint" email I sent out 
about two weeks ago:

"Other than critical bugfixes, this is effectively the end of Gutenprint 
 development, at least until a sufficient infusion of money and/or 
 manpower comes along."

In other words, it's not going to happen until someone volunteers (or 
pays for someone) to do it.  That someone will probably not be me.

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

[Gimp-print-devel] Accidentally deleted some emails

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

Someone sent me an email a couple of days ago that I inadvertantly 
deleted; It had a subject along the lines of Gutenprint producing weird 
characters or something like that.  It ended up in my spambox and I 
accidently deleted it before the subject line had fully registered in my 
mind.

If you get this, please resend?

Thanks,

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

[Gimp-print-devel] Gutenprint plugin for Gimp 3

[Alain S. <ala...@la...>]

"An enhanced Print plug-in for the GIMP."
What about a pritnt plugin for Gimp 3 ? When ?
Thanks in advance

Re: [Gimp-print-devel] peachcolored grayscale dye sublimation printer

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

On Thu, Mar 20, 2025 at 12:25:07AM +0100, AUTOBROS AB wrote:
> I have tried getting CUPS to use an ICC profile for printing but without
> success. I have also tried editing the PPD file, but again, without results.
> It seems like the Gutenprint driver lacks support for adjusting colors and
> ICC profiles.

Thre are two options, both require obtaining the ICC profiles from the 
printer manufacturers (included in their windows drivers, and sometimes 
as a separate download)

Then, you can either:

 * Pre-process the source images with the profile before you submit them 
   for printing.  (Since you're already using ImageMagick this is easy)
 * If your distribution uses colord (and CUPS is also built to use it) then
   you can import the ICC profiles and associate them with your printers using
   colord's tools (eg colormgr).  CUPS will then do the right thing automatically.

In both cases you'll need to submit a "color" image because even if the 
channels are the same going in, they won't be the same by the time 
they're submitted to the printer.

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

[Gimp-print-devel] peachcolored grayscale dye sublimation printer

[AUTOBROS AB <huv...@th...>]

*Hello!*

I am so grateful for all the work you put into Gutenprint. It’s fantastic!

I use Gutenprint in CUPS on an R-Pi with Bookworm OS. As printers, I use 
dye sublimation printers, both the Citizen CY02 and DNP-RX1.

The images I print are always taken in color and then processed in 
ImageMagick with an ICC profile that converts them to black and white 
(grayscale).

By the time the images reach the printer, they are already black and white.

My problem is that the printed images have a slight peach tint in the 
lighter grayscale areas. It doesn’t matter whether I select RGB or 
GRAYSCALE in CUPS; the result is the same. The only adjustments that 
seem to have any effect are "Gamma adjustments," but they don’t improve 
the image—only make it more peach-colored.

I have tried getting CUPS to use an ICC profile for printing but without 
success. I have also tried editing the PPD file, but again, without 
results. It seems like the Gutenprint driver lacks support for adjusting 
colors and ICC profiles.

Do you have any thoughts on how I should proceed?


All the best

Marcus

Re: [Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

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

Roy,

> On Mar 17, 2025, at 9:04 PM, Roy Harrington <ro...@ha...> wrote:
> ...
> What seems like a good feature would be a relatively simple way to just open a printer-name and have
> a simple connection to send a byte stream to the printer. Basically like the old " | lpr -o raw -P printer"
> Seems like this is the print application idea but without needing all the IPP knowledge and code.
> Is there an IPP equivalent? Would it be possible to easily do this?

OK, so this question comes up often enough...

It is technically possible to create an application that accepts arbitrary print files and sends them, unprocessed, to a network or USB printer.  However, if that is all that application does then you have basically just recreated raw printing a la MS-DOS.

The purpose of PAPPL and printer applications in general is to provide an integrated service that can support printing of both raw and standard file formats.  PAPPL hides all of the complexity of running an IPP service, with direct interfaces supporting "raw" and raster printing and support for filtering other kinds of files into printer-ready output.  Think of PAPPL as a "CUPS lite" service that allows you to develop printer drivers or RIPs that have a standard interface for other services to use.

________________________
Michael Sweet

Re: [Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

[Zdenek D. <zd...@re...>]

Hi Roy,

On 3/18/25 02:04, Roy Harrington wrote:
> What seems like a good feature would be a relatively simple way to 
> just open a printer-name and have
> a simple connection to send a byte stream to the printer. Basically 
> like the old " | lpr -o raw -P printer"
> Seems like this is the print application idea but without needing all 
> the IPP knowledge and code.
> Is there an IPP equivalent? Would it be possible to easily do this?

AFAIK current PAPPL supports raw socket functionality, which does the 
same as raw queue - just sends data to the printer.


Zdenek

>
> Thanks
> Roy Harrington
>
>
> On Mon, Mar 17, 2025 at 7:40 AM Michael Sweet via Gimp-print-devel 
> <gim...@li...> wrote:
>
>
>     Believe me, I understand your feelings entirely! :)
>
>     WRT the separate printer applications, I'm available as a resource
>     whether you just have questions about PAPPL or need changes made
>     to it.  I might even have some time to contribute some code...
>
>     ________________________
>     Michael Sweet
>
>
>
>     _______________________________________________
>     Gimp-print-devel mailing list
>     Gim...@li...
>     https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>
>
>
> -- 
> Roy Harrington
> ro...@ha...
> www.harrington.com <http://www.harrington.com>
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

-- 
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

Re: [Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

[Zdenek D. <zd...@re...>]

Hi Solomon and Michael,

I know that my contribution is only small portion in comparison to you 
and you have been doing so much for printing, so I actually feel bad to 
feel the same way as you.

I hope my help on CUPS and other OpenPrinting projects (although limited 
due my limited workday) eases the burden a little at least and I will do 
my best as Fedora gutenprint/gutenprint-printer-app maintainer too.


Zdenek

On 3/17/25 15:21, Michael Sweet via Gimp-print-devel wrote:
> Solomon,
>
>> On Mar 16, 2025, at 12:09 PM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
>> ...
>> Consequently, I think it makes more sense to build out a new printer
>> application that caters solely to these dyesub models.  It would borrow
>> some printer-specific code from Gutenprint (and re-use most of the
>> backend) but will otherwise be a clean-sheet implementation.  It still
>> faces numerous hurdles but not having to uplift the rest of Gutenprint
>> along the way will greatly reduce the overall project scope and
>> complexity.
>>
>> This also aligns with my personal interests, but unless other interested
>> parties step up with funding or other resources, it will remain a (very)
>> part-time effort, if it gets started at all -- My personal printing
>> needs can be met by just keeping an old CUPS installation around, and
>> I'd rather spend my evenings with my family and my weekends doing things
>> outside -- really, anything other than staring at a computer screen
>> performing unpaid commercial software development.
>>
>> Comments and feedback welcome.  Contributors even more so.
> Believe me, I understand your feelings entirely! :)
>
> WRT the separate printer applications, I'm available as a resource whether you just have questions about PAPPL or need changes made to it.  I might even have some time to contribute some code...
>
> ________________________
> Michael Sweet
>
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

-- 
Zdenek Dohnal
Senior Software Engineer
Red Hat, BRQ-TPBC

Re: [Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

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

Hi Roy;

Just noticed QuadToneRIP has support for my Epson SC P5000.  I'm hoping to improve support for all the inks on it using gutenprint or successor. I'll give your program a spin.

Erik
Sent from my iPhone

> On Mar 17, 2025, at 21:05, Roy Harrington <ro...@ha...> wrote:
> 
> QuadToneRIP

Re: [Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

[Roy H. <ro...@ha...>]

Hi Michael

As the author of QuadToneRIP I'm in much the same boat.  Since I use MacOS
as my main computer
I've been more committed to maintaining a Mac version.  So far so good, but
it seems the writing
is on the wall regarding regular old-style print drivers.
I've spent some time looking at IPP and PAPPL code but frankly I'm not
familiar enough to just jump right in.

What seems like a good feature would be a relatively simple way to just
open a printer-name and have
a simple connection to send a byte stream to the printer. Basically like
the old " | lpr -o raw -P printer"
Seems like this is the print application idea but without needing all the
IPP knowledge and code.
Is there an IPP equivalent? Would it be possible to easily do this?

Thanks
Roy Harrington


On Mon, Mar 17, 2025 at 7:40 AM Michael Sweet via Gimp-print-devel <
gim...@li...> wrote:

>
> Believe me, I understand your feelings entirely! :)
>
> WRT the separate printer applications, I'm available as a resource whether
> you just have questions about PAPPL or need changes made to it.  I might
> even have some time to contribute some code...
>
> ________________________
> Michael Sweet
>
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>


-- 
Roy Harrington
ro...@ha...
www.harrington.com

Re: [Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

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

Solomon,

> On Mar 16, 2025, at 12:09 PM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> ...
> Consequently, I think it makes more sense to build out a new printer 
> application that caters solely to these dyesub models.  It would borrow 
> some printer-specific code from Gutenprint (and re-use most of the 
> backend) but will otherwise be a clean-sheet implementation.  It still 
> faces numerous hurdles but not having to uplift the rest of Gutenprint 
> along the way will greatly reduce the overall project scope and 
> complexity.
> 
> This also aligns with my personal interests, but unless other interested 
> parties step up with funding or other resources, it will remain a (very) 
> part-time effort, if it gets started at all -- My personal printing 
> needs can be met by just keeping an old CUPS installation around, and 
> I'd rather spend my evenings with my family and my weekends doing things 
> outside -- really, anything other than staring at a computer screen 
> performing unpaid commercial software development.
> 
> Comments and feedback welcome.  Contributors even more so.

Believe me, I understand your feelings entirely! :)

WRT the separate printer applications, I'm available as a resource whether you just have questions about PAPPL or need changes made to it.  I might even have some time to contribute some code...

________________________
Michael Sweet

Re: [Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

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

Hello Solomon,

On 2025-03-16 17:09,
Solomon Peachy via Gimp-print-devel wrote (excerpts):
> 
> "Whomever does the actual work
>  gets to decide what/how it is done"
...
> they have created an XKCD #2347 situation.
...
> I'd rather spend my evenings with my family
> and my weekends doing things outside -- really,
> anything other than staring at a computer screen
> performing unpaid commercial software development.

YES!

I assume you do not owe them anything,
so I think as a Free Software developer
you have every right to do what is best for you
and leave them in their own XKCD #2347 situation.


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

[Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

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

Now that the long-delayed 5.3.5 release is out, it's time to talk about 
Gutenprint's future.

"Everyone wants to create, but nobody wants to maintain. There is no
 glory in maintenance."

Gutenprint itself is stable and mature.  While there are always areas 
for improvement, it generally does what it claims to do.  In that sense 
Gutenprint doesn't need much ongoing maintenance; just fixing bugs as 
they show up and occasionally adding support for addtional printers.  
This has effectively been the status quo for some time, but 
unfortunately, while Gutenprint itself is stable, the rest of the 
printing world is not.

For many years now, the greater printing ecosystem has been undergoing a 
foundational shift away from traditional OS/platform-specific printer 
drivers (such as Gutenprint) towards "driverless" IPP.  Nearly all 
printers released within the past five to ten years JustWork(tm) out of 
the box, using driverless IPP, either over a network connection or 
tunneled over USB.

In other words, modern printers don't generally need something like 
Gutenprint.  Meanwhile, older printers tend wear out so that over time, 
fewer and fewer remain in service.  (There are some notable exceptions, 
and we will get to that later)

 ~ ~ ~

Currently, CUPS itself acts as an driverless IPP wrapper around 
tradtional PPD-based CUPS drivers.  This will go away in the very near 
future, but the folks over at OpenPrinting came up with so-called 
"retrofit printer applications" that provide similar functionality in a 
self-contained manner.

Additionally, last fall a GSoC project created a "native" Gutenprint 
printer application around PAPPL.  This differs from the "retrofit" 
insofar as it directly interacts with libguenprint instead of its 
CUPS/PPD driver wrapper, but it is not in a usable state, and completing 
it may not actually make sense, for reasons to do with those 
aforementioned exceptions.

Basically, at this point, there are only two sets of "modern" printers 
that still need a traditional "driver" like Gutenprint:

 1) Models that provide an additional low-level/native protocol that 
    allows a much higher degree of control over what is exposed via IPP.

    Currently this includes high-end Epson Injket printers used to create 
    "fine art" prints, often involving bespoke ink and media.  These 
    printers expose numerous knobs to ensure the output can be carefully tuned
    to achieve the highest possible quality.

 2) Models that do not provide driverless IPP functionality at all.

    Specifically, high-speed dye-sublimation photo printers (such as 
    those used in photo booths or drugstore kiosks) and other/similar 
    models that are used in commercial/production-focused contexts.

Both of these tend to be expensive, have long product lifecycles (that 
routinely exceed a decade) and nearly always operated on a commercial 
basis; that is to say they are used to make money for their operators.

The current retrofit application will more than suffice for the folks 
that have an old printer and want to keep using it for typical 
home/office stuff. Similarly, it would not likely take too much effort 
to finish the incomplete native application to the point where it would 
be an effective replacement for the retrofit applicaiton for these 
tasks.

However, for those two sets of "modern" printers that we believe make up 
the primary user base of Gutenprint today, the incomplete application will
require *extensive* additional work before it would be usable.

For the high-end inkjets, a way to usably expose the numerous control 
knobs is utterly necessary.  As IPP (or more accurately, common IPP 
print clients) is not currently up for this task, this will likely need 
to be done from within the printer application itself, through some sort 
of (web-based) user interface; This needs to be planned, prototyped, 
developed, and maintained, and is likely to involve allowing the 
creation and management of selectable profiles that would potentially 
include adjustments to virtually every knob the printer supports. This 
is a _huge_ undertaking.

For the dye-sublimation models, the current retrofit application is not 
even usable because it completely lacks the custom USB backend, which 
needs to be ported and integrated to work within PAPPL.  There are 
additional UI/UX warts without easy solutions, and numerous other bits 
of functionality (eg extensive diagnostic information) that need to be 
exported, and architectural issues within Gutenprint itself that need 
addressing before we will be able to fully take advantage of the new 
functionality that IPP can enable.

This is on top of other work that Gutenprint desparately needs, 
including:

 * Finally migrate off of Sourceforge (likely to codeberg or sourcehut) 
 * Rework the www site into something modern and relevant
 * Finish cleaning up the littany of build warnings with modern compilers
 * Port the GIMP plugin to GIMP3 (ie GEGL and GTK3)
 * Modernize build system (eg modernized autotools or cmake)
 * etc

Most of these are in of themselves significant undertakings, requiring 
planning, development, and ongoing maintenance across a broad swath of 
skillsets.  The problem is... we don't have that.

At its peak, Gutenprint only ever had a handful of active contributors, 
but shortly after the 5.3.4 release that number fell to just one, where 
it has languished ever since. 

Even putting aside this large pile of TODOs, this is not a sustainable 
position.  What happens if that remaining person gets crushed by a tree?

 ~ ~ ~

The bottom line is that as things stand today, none of this work will 
happen.  Or if it happens at all, it will be on an extremely glacial 
scale, driven primarily by the self-interest and time availability of 
that one contributor.

This is not just a matter of *funding*, except in the sense that a 
sufficient amount of guaranteed funding can be used to pay for 
suitably-skilled contributors.

As a poignant example of this, over the course of the past three 
summers, Google sponsored three GSoC attempts to create a Gutenprint 
printer application. The first two completely ghosted us, and the third 
looked to be heading in the same direction before they unexpectedly 
delivered delivered passable (if incomplete) code at the 11th hour.  

Even at the lowest end of the GSoC compensation scale, these three 
students were collectively paid at least triple the amount of funding 
that Gutenprint itself received during the same time period.  This is 
actually much worse than it sounds; if not for a generous 
no-strings-attached "thank you" donation from a commerciaal ISV, the 
total donations over that three year period would have totaled less than 
$160!  This greatly-appreciated donation didn't fully cover Gutenprint's 
_costs_ (eg acquiring hardware and media) over that same period.

It is clear these GSoC participants did so for the stipend rather than 
of any interest in Gutenprint or printing in of itself.  There is 
nothing inherently wrong with that, but when one factors in the time and 
effort Gutenprint (and OpenPrinting) spent on mentoring, it was probably 
a net loss when one considers that none of the participants elected to 
continue contributing after they were no longer being paid to do so.

Frustratingly, if those same funds had been paid directly to Gutenprint 
instead, it would have all but guaranteed completion of the scoped work, 
and likely much more.  But that window of opportunity/availability has 
long since closed.

 ~ ~ ~

There are two general rules in play.  The first is the so-called golden 
rule -- "Whomever has the gold, makes the rules". If there is no gold 
involved, the second rule kicks in -- "Whomever does the actual work 
gets to decide what/how it is done"

Given that there is nobody waving around any gold, and there is only one
person doing any work, where does that leave Gutenprint?

 * Will stay on Sourceforge for the time being
 * No feature development planned
 * No additional printer support planned
 * Gutenprint will continue receiving bugfixes as needed
 * Folks can use the retrofit printer application when CUPS finally 
   drops the guillotine on PPD-based drivers
 * No plans to resume work on the WIP native printer application

In other words, other than critical bugfixes, this is effectively the 
end of Gutenprint development, at least until a sufficient infusion of 
money and/or manpower comes along.  Or that one contributor gets taken 
out by some sort of Florida Man shennanigans.

 ~ ~ ~

What would be considered "sufficent"?  We don't have a good answer for 
that, but it's going to be infinitely larger than the 'nothing' of today.

While we don't begrudge folks from making money using Free Software, 
when most of Gutenprint's userbase (or at least the portion that would 
benefit the most from this work) is actively using it to make money, one 
tends to get a grumpy when you realize everyone other than you is 
getting paid.  This is not an exaggeration; entire industry verticals 
have been built on top of Gutenprint.

Logically, one would expect printer manufacturers to consider it in 
their best interest to ensure their printers are well supported under 
Linux -- even at the minimal level of providing documentation and loaner 
models would be beneficial, as opposed to sending legal nastygrams while 
their own salescritters are actively sending Gutentprint builds to their 
customers!  (This has happened more than once)

Logically, one would expect systems integrators to treat Gutenprint as a 
critical supplier instead of an infinite free resource (and nearly 
inevitably violating Gutenprint's GPL license along the way..)

Instead, they have created an XKCD #2347 situation.

 ~ ~ ~

So, all that said, where would this contributor like to see things go, 
if sufficient time and/or money was made available?

(Horay, no more speaking in the third person)

As one can probably surmise from the wall of text preceding this, I 
don't think it's worth continuing meaningful work on "classic" 
Gutenprint.  The retrofit application will work fine for folks with 
ancient printers until they inevitably fall to prey to the vagracies of 
time.

The glaring exception to this are dye-sublimiation (and other thermal) 
printers. Indeed, over at least the past five years these have 
represented the primary area of (expressed) user interest and actual 
deploments.  (There's also the aforementioned Epson injkets, but that's 
not something I personally care about)

Consequently, I think it makes more sense to build out a new printer 
application that caters solely to these dyesub models.  It would borrow 
some printer-specific code from Gutenprint (and re-use most of the 
backend) but will otherwise be a clean-sheet implementation.  It still 
faces numerous hurdles but not having to uplift the rest of Gutenprint 
along the way will greatly reduce the overall project scope and 
complexity.

This also aligns with my personal interests, but unless other interested 
parties step up with funding or other resources, it will remain a (very) 
part-time effort, if it gets started at all -- My personal printing 
needs can be met by just keeping an old CUPS installation around, and 
I'd rather spend my evenings with my family and my weekends doing things 
outside -- really, anything other than staring at a computer screen 
performing unpaid commercial software development.

Comments and feedback welcome.  Contributors even more so.

But any proposal that entails my undertaking _more_ unpaid work for 
other folks' benefit will be mercilessly mocked.  This goes double for 
suggesions on how to make Gutenprint "more attractive to potential 
contributors" unless that suggestion comes in the form of a bag of 
cash.

 - 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] Uninstall gutenprint

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

> On Mar 15, 2025, at 9:02 AM, Sidath Baranage <sid...@gm...> wrote:
> 
> Hi,
> 
> How do I completely uninstall Gutenprint from my mac?

The uninstaller is on the disk image that contains the installer.  After running the uninstaller, you will have to manually delete any printers using Gutenprint.

Matt

[Gimp-print-devel] Uninstall gutenprint

[Sidath B. <sid...@gm...>]

Hi,

How do I completely uninstall Gutenprint from my mac?

Regards,
-- 
Sidath Baranage

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

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

Thank you!
Sent from my iPhone

> On Mar 12, 2025, at 16:37, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> Gutenprint 5.3.5 is a stable release of the 5.3 series.  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/gutenprint-5.3.5.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 is only distributed in source form; third parties (such
> as Linux distriutions) typically prepare and distribute binaries for
> their systems.
> 
> This release is primarily a roundup of the various additions and minor
> fixes that have accumulated in the four years since the 5.3.4 release in
> late 2020.
> 
> 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.
> 
>     MacOS-specific contributions will continue be accepted.
> 
>     This release includes a workaround for a printer dialog crash on MacOS
>     if the PPD includes support for custom CD/DVD sizes.  This was
>     resolved by removing that option altogether for MacOS builds.
> 
>  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)
>     Joyspace U826 / SwiftFoto KSF-10R
>     Mitsubishi CP-W5000 series
>     Mitsubishi CP-D90DW-SL
>     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)
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> <signature.asc>

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

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

Thanks for releasing!

There is still the bug I reported earlier that
"-D_POSIX_C_SOURCE=200809L" is added on all systems, rather than only on
those where it is needed/helpful.  Adding a visibility define asks to
hide all system functions not required by that standard.  The code uses
netinet/ip.h which is not specified.  I'm patching this out, which is
not hard.



In updating pkgsrc, I was reminded that gimp 3 is within measurable
distance of release.  Actually checking, it has happened.
  https://testing.gimp.org/news/2025/03/09/gimp-3-0-released/

I have already removed gimp 2 and installed an RC of 3, and thus didn't
want to uninstall and build 2 to test building gutenprint.  Really, it's
that I expect that the people who would use gutenprint in pkgsrc (I
really have no idea how big that number is) would be using gimp 3, for
the same reasons I am.

Reading configure.ac, it looks like the gimp plugin really is gimp2
only.  I realize it's a lot of work to make a gimp3 plugin.

All in all, I decided to make the gimp option default off.  People that
want it can rebuild.

Does this seem reasonable?   What are other packaging systems doing,
that have gimp3?  Opinions?

[Gimp-print-devel] Gutenprint 5.3.5 Release

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

Gutenprint 5.3.5 is a stable release of the 5.3 series.  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/gutenprint-5.3.5.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 is only distributed in source form; third parties (such 
as Linux distriutions) typically prepare and distribute binaries for 
their systems.

This release is primarily a roundup of the various additions and minor 
fixes that have accumulated in the four years since the 5.3.4 release in 
late 2020.

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.

     MacOS-specific contributions will continue be accepted.

     This release includes a workaround for a printer dialog crash on MacOS
     if the PPD includes support for custom CD/DVD sizes.  This was
     resolved by removing that option altogether for MacOS builds.

  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)
     Joyspace U826 / SwiftFoto KSF-10R
     Mitsubishi CP-W5000 series
     Mitsubishi CP-D90DW-SL
     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] 5.3.5 release blocker

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

Will do! 

And thanks Matt for pitching in already.

Erik
Sent from my iPhone

> On Mar 6, 2025, at 11:57, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Thu, Mar 06, 2025 at 10:34:42AM -0500, Erik Beck of Tahoma wrote:
>> Please let us know how we can help.
> 
> Please grab the latest snapshot (2025-03-06T10-32 as I write this) and
> make sure it works with your printer(s).
> 
> (dyesub, pcl, epson, canon, everything you have)
> 
> - Solomon
> --
> Solomon Peachy                  pizza at shaftnet dot org (email&xmpp)
>                                      @pizza:shaftnet dot org   (matrix)
> Dowling Park, FL                      speachy (libera.chat)
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> <signature.asc>

Re: [Gimp-print-devel] 5.3.5 release blocker

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

> On Mar 6, 2025, at 1:02 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Thu, Mar 06, 2025 at 11:29:34AM -0600, Matt Broughton wrote:
>> It crashes on 'Making all in cups' on macos Sonoma 14.7.3.  Two file attached--1. crash in making cups; 2. full terminal output from ./configure to crash during make.
> 
> This seems to be due to someting that the 14.7 MacOS CUPS headers now need.
> 
> Ought to be an easy thing to fix -- ie add the appropriate #include -- 
> but figuring that out is beyond my remit.

How quickly I forget.  macos cannot handle -D_POSIX_C_SOURCE=200809L in configure at  # C99 + POSIX extras.

Everything builds fine now.  One file printer tested OK.  I'll have to see what actual printers I can find that might still be functional.

Matt

Re: [Gimp-print-devel] 5.3.5 release blocker

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

On Thu, Mar 06, 2025 at 11:29:34AM -0600, Matt Broughton wrote:
> It crashes on 'Making all in cups' on macos Sonoma 14.7.3.  Two file attached--1. crash in making cups; 2. full terminal output from ./configure to crash during make.

This seems to be due to someting that the 14.7 MacOS CUPS headers now need.

Ought to be an easy thing to fix -- ie add the appropriate #include -- 
but figuring that out is beyond my remit.

 - 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] 5.3.5 release blocker

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

> On Mar 6, 2025, at 10:57 AM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Thu, Mar 06, 2025 at 10:34:42AM -0500, Erik Beck of Tahoma wrote:
>> Please let us know how we can help.
> 
> Please grab the latest snapshot (2025-03-06T10-32 as I write this) and 
> make sure it works with your printer(s).
> 
> (dyesub, pcl, epson, canon, everything you have)

It crashes on 'Making all in cups' on macos Sonoma 14.7.3.  Two file attached--1. crash in making cups; 2. full terminal output from ./configure to crash during make.

There are also a lot of warnings which usual.

Matt

Re: [Gimp-print-devel] 5.3.5 release blocker

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

On Thu, Mar 06, 2025 at 10:34:42AM -0500, Erik Beck of Tahoma wrote:
> Please let us know how we can help.

Please grab the latest snapshot (2025-03-06T10-32 as I write this) and 
make sure it works with your printer(s).

(dyesub, pcl, epson, canon, everything you have)

 - 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] 5.3.5 release blocker

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

Thanks for the update!

Please let us know how we can help.

Erik


On Thu, 6 Mar 2025 08:26:41 -0500
Solomon Peachy via Gimp-print-devel
<gim...@li...> wrote:

> The short version: It's being held up by release blocker bugs.
> 
> The current holdup is a nasty margin-related bug that manifests
> itself as garbled printouts when producing 2x6" strips, but only with
> certian dyesub models and even then, depending on how the printjob is
> submitted to CUPS (eg as a pdf vs jpeg) it doesn't occur.
> 
> Essentially, the image data is submitted in a portrait orientiation,
> but needs to be rotated as the printer needs landscape oriented data,
> but under some circumstances (where there is a non-zero non-printable
> margin on the LEFT side) this transformation isn't being performed
> properly, but the data is read out as if it has.
> 
> I was able to work around the problem insofar as the rotation now
> always occurs, but I noticed the first colunm (or four) of the output
> data is still being garbled.  There is clearly still a boundary
> off-by-one error going on, and I strongly suspect it has been here
> for a _long_ time, but is not normally visible as it falls outside of
> page margins.
> 
> While trying to hunt this one down, I've been cleaning up many of the 
> spurious build warnings to hopefully expose stuff that matters, but 
> managed to introduce outright crashes in the injket dithering code
> along the way.  Turns out there are some real bugs lurking there too,
> likely of the "cancel each other out" variety.
> 
> (Ah, the joy of technical debt in a 25-year-old codebase..)
> 
>  - Solomon

[Gimp-print-devel] 5.3.5 release blocker

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

The short version: It's being held up by release blocker bugs.

The current holdup is a nasty margin-related bug that manifests itself 
as garbled printouts when producing 2x6" strips, but only with certian 
dyesub models and even then, depending on how the printjob is submitted 
to CUPS (eg as a pdf vs jpeg) it doesn't occur.

Essentially, the image data is submitted in a portrait orientiation, but 
needs to be rotated as the printer needs landscape oriented data, but 
under some circumstances (where there is a non-zero non-printable margin 
on the LEFT side) this transformation isn't being performed properly, 
but the data is read out as if it has.

I was able to work around the problem insofar as the rotation now always 
occurs, but I noticed the first colunm (or four) of the output data is 
still being garbled.  There is clearly still a boundary off-by-one error 
going on, and I strongly suspect it has been here for a _long_ time, but 
is not normally visible as it falls outside of page margins.

While trying to hunt this one down, I've been cleaning up many of the 
spurious build warnings to hopefully expose stuff that matters, but 
managed to introduce outright crashes in the injket dithering code along 
the way.  Turns out there are some real bugs lurking there too, likely 
of the "cancel each other out" variety.

(Ah, the joy of technical debt in a 25-year-old codebase..)

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