Menu
▾
▴
gimp-print-devel
|
From: Solomon P. <pi...@sh...> - 2025-03-06 13:27:01
Attachments:
signature.asc
|
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)
|
|
From: Erik B. of T. <ba...@ta...> - 2025-03-06 15:50:59
|
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 |
|
From: Solomon P. <pi...@sh...> - 2025-03-06 16:57:27
Attachments:
signature.asc
|
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)
|
|
From: Bacon At T. <ba...@ta...> - 2025-03-07 12:31:35
|
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> |
|
From: Matt B. <wal...@ma...> - 2025-03-06 17:54:52
|
> 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 |
|
From: Solomon P. <pi...@sh...> - 2025-03-06 19:02:28
Attachments:
signature.asc
|
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)
|
|
From: Matt B. <wal...@ma...> - 2025-03-06 20:14:34
|
> 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 |
Thanks for helping keep SourceForge clean.
X