gimp-print-devel

Re: [Gimp-print-devel] New Printer Debugging Strategy Help

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

On Mon, Jul 29, 2024 at 07:56:16AM -0400, Erik Beck of Tahoma wrote:
> I ran a make check, and everything passed (4hrs 46m, 44s on an AMD
> Ryzen 9 7900X 12-Core Processor).

Try running 'make check-parallel'  :D

> When testing my build for this printer, rastertogutenprint crashes with
> a signal 6 (SIGABRT).

That's .. odd.

> Crashfile is generated with this info towards the top:
> ProcCmdline: EPSON_SC-P5000_Series 23 erikbeck Test\ Page 1
> job-uuid=urn:uuid:e7035dd6-08e8-303f-50b4-e8cbf5e479f9\
> job-originating-host-name=localhost\ date-ti me-at-creation=\
> date-time-at-processing=\ time-at-creation=1722196107\
> time-at-processing=1722196107

Does that automatic crash log include a core dump?  That should be able 
to tell you what went wrong where..

Also, run ./configure with --enable-debug as that will adjust the 
compile options to make debugging easier.

> How can I test this filter outside of the normal chain so I might get 
> more insight into what is going on? Other strategies?

This is an example of what I use to run filters in isolation:

 # pull these two from your printers.conf
 export CUPS_URI="gutenprint53+usb://HiTi/P520L?serial=2WC4A1013968279"
 export DEVICE_URI="gutenprint53+usb://HiTi/P520L?serial=2WC4A1013968279"
 # Snag from /etc/cups/ppd or generate with cups-genppd.5.3
 export PPD="stp-dnp-p520l.5.3.ppd"
 # these don't matter but need to be set
 export id="123"
 export user="me"
 export title="image test"
 export copies="1"
 # And whatever non-default print options you want 
 export OPTIONS="PageSize=w324h576"

 # convert image to CUPSraster (only need to do this once if the options or PPD don't change)
 /usr/lib/cups/filter/imagetoraster "$id" "$user" "$title" "$copies" "$OPTIONS" image.ppm > image.raster
 # generate spool file for printer (what you probably care about)
 /usr/lib/cups/filter/rastertogutenprint.5.3 "$id" "$user" "$title" "$copies" "$OPTIONS" image.raster > image.raw
 # Send it to the printer (optional)
 cat image.raw | /usr/lib/cups/backend/gutenprint53+usb "$id" "$user" "$title" "$copies" "$OPTIONS" 



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

[Gimp-print-devel] New Printer Debugging Strategy Help

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

Hello all,

I could use some help on debugging strategies for rastertogutenprint.

I am working on supporting an Epson SureColor P-5000, using the latest
interim release of 5.3.5-pre1.

I ran a make check, and everything passed (4hrs 46m, 44s on an AMD
Ryzen 9 7900X 12-Core Processor).

When testing my build for this printer, rastertogutenprint crashes with
a signal 6 (SIGABRT).

Crashfile is generated with this info towards the top:
ProcCmdline: EPSON_SC-P5000_Series 23 erikbeck Test\ Page 1
job-uuid=urn:uuid:e7035dd6-08e8-303f-50b4-e8cbf5e479f9\
job-originating-host-name=localhost\ date-ti me-at-creation=\
date-time-at-processing=\ time-at-creation=1722196107\
time-at-processing=1722196107


How can I test this filter outside of the normal chain so I might get
more insight into what is going on? Other strategies?

Thanks!

Erik

Re: [Gimp-print-devel] Printer problem with brother HL-1112R

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

On Sat, Jul 20, 2024 at 02:35:10PM +0300, serwer2008--- via Gimp-print-devel wrote:
> Is it possible to include it in the list of supported devices printer 
> brother HL-1112R? Brother HL-1112R printer dose not works in haiku os. 
> I tried all printer drivers, different models. The guteprint driver 
> was used.

The HL-1112 appears to be a minimal PCL5e-based device.

So try using "generic PCL5 printer" or "Laserjet 5L"

Best of luck,

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

[Gimp-print-devel] (no subject)

[Jesus L. <jes...@gm...>]

Cuents

[Gimp-print-devel] Printer problem with brother HL-1112R

[<ser...@ic...>]

Dear developers,
Is it possible to include it in the list of supported devices printer brother HL-1112R? Brother HL-1112R printer dose not works in haiku os. I tried all printer drivers, different models. The guteprint driver was used.
Best wishes,
Vanya
Картинкиdriver was used.The printer is fully operational.

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

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

I definitely support fleeing from source forge.
Sent from my iPhone

> On Jul 9, 2024, at 18:29, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Tue, Jul 09, 2024 at 07:49:34PM -0400, Greg Troxel wrote:
>> This really seems buggy of sourceforge, and seems to be hostile to
>> packaging.  I am guessing this is just how it is, and there's not much
>> to be done, other than skipping github and moving to codeberg :-)
> 
> I'd probably jump straight to sourcehut instead, because I prefer email.
> 
> ...just have to get this release out the door before I can figure out 
> what to do next.  I'd rather self-host than stay on sourceforge.
> 
>> I am curious if other packagers also find this troublesome.  They might
>> well not; this is just a collision between pkgsrc assuming
>> near-universal practice and sourceforge being odd.
> 
> I honestly don't know.
> 
>>>  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.
>> 
>> I'm hoping that a posix-type build on macos is ok, but if not we can
>> mark the pkgsrc package BROKEN.
> 
> Given that we have to integrate with the MacOS printing subsystem and 
> directly speak to attached USB devices, I don't believe a posix-type 
> build has been sufficient for something like a decade..
> 
> - 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-pre1 Release

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

> On Jul 11, 2024, at 9:26 AM, Greg Troxel <gd...@le...> wrote:
> 
> Solomon Peachy via Gimp-print-devel
> <gim...@li...> writes:
> 
>> On Wed, Jul 10, 2024 at 08:26:56PM -0400, Greg Troxel wrote:
>>> Strictly, a program should specify --std=cNN for the variant it is
>>> written in.  But I think the default -- so far -- is almost always c99
>>> so often this doesn't happen.
>> 
>> gcc jumped from 'gnu89' straight to 'gnu11' and currently defaults to 
>> 'gnu17'.  At no point did GCC ever default to c99 (or gnu99).
> 
> Wow, but I learn something new every day.  Anyway, I think we'll all
> happy with --std=c99.
> 
>>> I ran make check, and it passed ppds and is still going.
>> 
>> This will take some hours depending on the speed of your system.
> 
> It took 12 hours, and that's on a 9th-gen i7!  But I got a clean pass.
> 
>> What does 'man strdup' and 'man localtime_r' list as requirements for 
>> use on these problematic platforms?
> 
> On NetBSD, strdup says the following (leaving out stuff in the middle)
> and it works without any defines.
> 
>  SYNOPSIS
>       #include <string.h>
> 
>       char *
>       strdup(const char *str);
> 
>       char *
>       strndup(const char *str, size_t len);
> 
>  STANDARDS
>       The strdup() function conforms to IEEE Std 1003.1-2001 (“POSIX.1”).
> 
>  HISTORY
>       The strdup() function first appeared in 4.4BSD.  The strndup() function
>       was added in NetBSD 4.0.
> 
> man localtime_r says:
> 
>  SYNOPSIS
>       #include <time.h>
> 
>       struct tm *
>       localtime_r(const time_t * restrict clock, struct tm * restrict result);
> 
>  STANDARDS
>       The ctime(), difftime(), asctime(), localtime(), gmtime() and mktime()
>       functions conform to ANSI X3.159-1989 (“ANSI C89”).  Rest of the
>       functions conform to IEEE Std 1003.1-2008 (“POSIX.1”).
> 

macos 12.7.5 responds as--
man strdup
NAME
     strdup, strndup – save a copy of a string

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <string.h>

     char *
     strdup(const char *s1);

     char *
     strndup(const char *s1, size_t n);

DESCRIPTION
     The strdup() function allocates sufficient memory for a copy of the string
     s1, does the copy, and returns a pointer to it.  The pointer may
     subsequently be used as an argument to the function free(3).

     If insufficient memory is available, NULL is returned and errno is set to
     ENOMEM.

     The strndup() function copies at most n characters from the string s1
     always NUL terminating the copied string.

SEE ALSO
     free(3), malloc(3)

HISTORY
     The strdup() function first appeared in 4.4BSD.  The strndup() function was
     added in FreeBSD 7.2.

macOS 12.7                      December 5, 2008                      macOS 12.7

=======================================
man localtime_r
CTIME(3)                    Library Functions Manual                    CTIME(3)

NAME
     asctime, asctime_r, ctime, ctime_r, difftime, gmtime, gmtime_r, localtime,
     localtime_r, mktime, timegm, timelocal – transform binary date and time
     values

LIBRARY
     Standard C Library (libc, -lc)

SYNOPSIS
     #include <time.h>

     extern char *tzname[2];

     char *
     asctime(const struct tm *timeptr);

...

SEE ALSO
     date(1), gettimeofday(2), getenv(3), time(3), tzset(3), tzfile(5)

STANDARDS
     The asctime(), ctime(), difftime(), gmtime(), localtime(), and mktime()
     functions conform to ISO/IEC 9899:1990 (“ISO C90”), and conform to ISO/IEC
     9945-1:1996 (“POSIX.1”) provided the selected local timezone does not
     contain a leap-second table (see zic(8)).

     The asctime_r(), ctime_r(), gmtime_r(), and localtime_r() functions are
     expected to conform to ISO/IEC 9945-1:1996 (“POSIX.1”) (again provided the
     selected local timezone does not contain a leap-second table).

     The timegm() function is not specified by any standard; its function cannot
     be completely emulated using the standard functions described above.

HISTORY
     This manual page is derived from the time package contributed to Berkeley
     by Arthur Olson and which appeared in 4.3BSD.

BUGS
     Except for difftime(), mktime(), and the _r() variants of the other
     functions, these functions leaves their result in an internal static object
     and return a pointer to that object.  Subsequent calls to these function
     will modify the same object.

     The C Standard provides no mechanism for a program to modify its current
     local timezone setting, and the POSIX-standard method is not reentrant.
     (However, thread-safe implementations are provided in the POSIX threaded
     environment.)

     The tm_zone field of a returned tm structure points to a static array of
     characters, which will also be overwritten by any subsequent calls (as well
     as by subsequent calls to tzset(3) and tzsetwall(3)).

     Use of the external variable tzname is discouraged; the tm_zone entry in
     the tm structure is preferred.

macOS 12.7                       January 2, 1999                      macOS 12.7

Matt

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

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

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

> On Wed, Jul 10, 2024 at 08:26:56PM -0400, Greg Troxel wrote:
>> Strictly, a program should specify --std=cNN for the variant it is
>> written in.  But I think the default -- so far -- is almost always c99
>> so often this doesn't happen.
>
> gcc jumped from 'gnu89' straight to 'gnu11' and currently defaults to 
> 'gnu17'.  At no point did GCC ever default to c99 (or gnu99).

Wow, but I learn something new every day.  Anyway, I think we'll all
happy with --std=c99.

>> I ran make check, and it passed ppds and is still going.
>
> This will take some hours depending on the speed of your system.

It took 12 hours, and that's on a 9th-gen i7!  But I got a clean pass.

> What does 'man strdup' and 'man localtime_r' list as requirements for 
> use on these problematic platforms?

On NetBSD, strdup says the following (leaving out stuff in the middle)
and it works without any defines.

  SYNOPSIS
       #include <string.h>

       char *
       strdup(const char *str);

       char *
       strndup(const char *str, size_t len);

  STANDARDS
       The strdup() function conforms to IEEE Std 1003.1-2001 (“POSIX.1”).

  HISTORY
       The strdup() function first appeared in 4.4BSD.  The strndup() function
       was added in NetBSD 4.0.

man localtime_r says:

  SYNOPSIS
       #include <time.h>

       struct tm *
       localtime_r(const time_t * restrict clock, struct tm * restrict result);

  STANDARDS
       The ctime(), difftime(), asctime(), localtime(), gmtime() and mktime()
       functions conform to ANSI X3.159-1989 (“ANSI C89”).  Rest of the
       functions conform to IEEE Std 1003.1-2008 (“POSIX.1”).


>> I don't have an inkjet printer any more, but from my viewpoint the only
>> thing wrong is the POSIX_C_SOURCE define.
>
> Upstream will _not_ apply this as it will break compilation on 
> bog-standard Linux systems.

I am not really saying you should never define it.  Just that you should
only define it on systems known to need it, where any remediation of
defining additional visibility defines can be done.

When you use a visibility define, then the system is supposed to hide
everything that is not required by that define.  I am unclear on the
relationship of system headers to these, specifically if there is an
expectation that system headers that are *not* required by that posix
level will work.  People often (on NetBSD) define _NETBSD_SOURCE, to get
back the things that are beyond posix that are defined by NetBSD.

I find it strange that strdup is not available on Linux without a define,
given that it has been in base posix since 2001 and is from 4.4BSD which
is roughly contemperaneous with the start of Linux.  But if that's how
it is that's how it is.

I compiled this hacky test program on Raspberry Pi OS 12 (which is
~debian):

  #include <string.h>

  int
  main()
  {
    char *a, *b;

    a = "foo";

    b = strdup(a);

    return 0;
  }

and it compiled without warnings.  It also compiled without warnings on
real Debian 12 (x86_64), which has gcc 12.2.0.



If you aren't willing to basically guard the _POSIX_C_SOURCE define with
"#if linux", then please at least omit it if NetBSD or macOS.  It is
likely it needs to be omitted the rest of the BSDs as well.



I append NetBSD's sys/featuretest.h.   As far as I know this is what is
supposed to happen.

  /*      $NetBSD: featuretest.h,v 1.10 2013/04/26 18:29:06 christos Exp $        */

  /*
   * Written by Klaus Klein <kl...@Ne...>, February 2, 1998.
   * Public domain.
   *
   * NOTE: Do not protect this header against multiple inclusion.  Doing
   * so can have subtle side-effects due to header file inclusion order
   * and testing of e.g. _POSIX_SOURCE vs. _POSIX_C_SOURCE.  Instead,
   * protect each CPP macro that we want to supply.
   */

  /*
   * Feature-test macros are defined by several standards, and allow an
   * application to specify what symbols they want the system headers to
   * expose, and hence what standard they want them to conform to.
   * There are two classes of feature-test macros.  The first class
   * specify complete standards, and if one of these is defined, header
   * files will try to conform to the relevant standard.  They are:
   *
   * ANSI macros:
   * _ANSI_SOURCE                 ANSI C89
   *
   * POSIX macros:
   * _POSIX_SOURCE == 1           IEEE Std 1003.1 (version?)
   * _POSIX_C_SOURCE == 1         IEEE Std 1003.1-1990
   * _POSIX_C_SOURCE == 2         IEEE Std 1003.2-1992
   * _POSIX_C_SOURCE == 199309L   IEEE Std 1003.1b-1993
   * _POSIX_C_SOURCE == 199506L   ISO/IEC 9945-1:1996
   * _POSIX_C_SOURCE == 200112L   IEEE Std 1003.1-2001
   * _POSIX_C_SOURCE == 200809L   IEEE Std 1003.1-2008
   *
   * X/Open macros:
   * _XOPEN_SOURCE                System Interfaces and Headers, Issue 4, Ver 2
   * _XOPEN_SOURCE_EXTENDED == 1  XSH4.2 UNIX extensions
   * _XOPEN_SOURCE == 500         System Interfaces and Headers, Issue 5
   * _XOPEN_SOURCE == 520         Networking Services (XNS), Issue 5.2
   * _XOPEN_SOURCE == 600         IEEE Std 1003.1-2001, XSI option
   * _XOPEN_SOURCE == 700         IEEE Std 1003.1-2008, XSI option
   *
   * NetBSD macros:
   * _NETBSD_SOURCE == 1          Make all NetBSD features available.
   *
   * If more than one of these "major" feature-test macros is defined,
   * then the set of facilities provided (and namespace used) is the
   * union of that specified by the relevant standards, and in case of
   * conflict, the earlier standard in the above list has precedence (so
   * if both _POSIX_C_SOURCE and _NETBSD_SOURCE are defined, the version
   * of rename() that's used is the POSIX one).  If none of the "major"
   * feature-test macros is defined, _NETBSD_SOURCE is assumed.
   *
   * There are also "minor" feature-test macros, which enable extra
   * functionality in addition to some base standard.  They should be
   * defined along with one of the "major" macros.  The "minor" macros
   * are:
   *
   * _REENTRANT
   * _ISOC99_SOURCE
   * _ISOC11_SOURCE
   * _LARGEFILE_SOURCE            Large File Support
   *              <http://ftp.sas.com/standards/large.file/x_open.20Mar96.html>
   */

  #if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE)
  #define _POSIX_C_SOURCE 1L
  #endif

  #if !defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && \
      !defined(_XOPEN_SOURCE) && !defined(_NETBSD_SOURCE)
  #define _NETBSD_SOURCE 1
  #endif

  #if ((_POSIX_C_SOURCE - 0) >= 199506L || (_XOPEN_SOURCE - 0) >= 500) && \
      !defined(_REENTRANT)
  #define _REENTRANT
  #endif

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

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

On Wed, Jul 10, 2024 at 08:26:56PM -0400, Greg Troxel wrote:
> Strictly, a program should specify --std=cNN for the variant it is
> written in.  But I think the default -- so far -- is almost always c99
> so often this doesn't happen.

gcc jumped from 'gnu89' straight to 'gnu11' and currently defaults to 
'gnu17'.  At no point did GCC ever default to c99 (or gnu99).

> I ran make check, and it passed ppds and is still going.

This will take some hours depending on the speed of your system.

> I don't have an inkjet printer any more, but from my viewpoint the only
> thing wrong is the POSIX_C_SOURCE define.

Upstream will _not_ apply this as it will break compilation on 
bog-standard Linux systems.

What does 'man strdup' and 'man localtime_r' list as requirements for 
use on these problematic platforms?

 - 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] Gutenprint 5.3.5-pre1 Release

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

BLUF:
  - configure.ac should be modified to remove "-D_POSIX_C_SOURCE=200809L"
  - configure.ac should remove the --std=c99 and add AC_PROG_CC_C99

Matt Broughton <wal...@ma...> writes:

> It does build fine on macos 12.7.5 with -std=c99.  I was going on what
> the previous macos maintainer indicated needed to be changed.  I am
> wondering if the macos builds ever used -std=c99.

Pedantically C is a language family and K&R C, ANSI C, c99, c11, c23
etc. are languages.  But that terminology doesn't help and people call
them "language family variants" or some such.  A compiler typically
supports multiple variants, and has a default for one of them.
Strictly, a program should specify --std=cNN for the variant it is
written in.  But I think the default -- so far -- is almost always c99
so often this doesn't happen.

  https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

So the --std=c99 seems right to me.

> configure line19887---
>   for stp_ac_arg in -Wall -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wwrite-strings -Werror-implicit-function-declaration -Winline -Wformat=2 -finline-limit=131072 -Wformat -Werror=format-security -D_POSIX_C_SOURCE=200809L -std=c99 ; do

The real question is what is in the configure.ac and why.  For
5.3.5-pre1, it's just coded to use those flags on gcc.  But it also
thinks clang is a kind of gcc, probably because clang has had to be very
compatible to survive (a bug in the gcc-using community, but that's off
topic).

  dnl Compiler flags                                                                                                                                                                                                            
  if test x$ac_compiler_gnu = "xyes"; then
    STP_ADD_COMPILER_ARGS([-Wall -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wwrite-strings -Werror-implicit-function-declaration -Winline -Wformat=2 -finline-limit=131072 \
  -Wformat -Werror=format-security] -D_POSIX_C_SOURCE=200809L -std=c99,, [GNUCFLAGS])
    if test x${USE_MAINTAINER_MODE} = xyes ; then
      STP_ADD_COMPILER_ARGS([ -pedantic -Waggregate-return -Wcast-qual -Wshadow -Wredundant-decls],, [GNUCFLAGS])
    fi
    if test x$ENABLE_DEBUG = xyes ; then
      STP_ADD_COMPILER_ARG([-g])
      STP_ADD_COMPILER_ARG([-Og])
    else
      STP_ADD_FIRST_COMPILER_ARG([-O3 -O2 -O1 -O])
    fi
  else
    if test x$ENABLE_DEBUG = xyes ; then
      STP_ADD_COMPILER_ARG([-g])
      STP_ADD_COMPILER_ARG([-Og])
    else
      STP_ADD_FIRST_COMPILER_ARG([-O])
    fi
  fi
  if test x$ENABLE_PROFILE = xyes ; then
    STP_ADD_COMPILER_ARG([-pg])
  fi
  AC_SUBST(GNUCFLAGS)

I'm guessing that the args in brackets are added if they work in a test
compile, and otherwise skipped.

I would say that:

  1) I am unclear on if standards require that compilers that implement c99
  accept --std=c99, and if there are any compilers that implement c99
  but don't take the option.  I would tend to use autoconf's macro:

     https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/C-Compiler.html
     AC_PROG_CC_C99

  and drop c99 from this stanza.  But I don't think it's causing trouble
  how it is.

  2) Setting _POSIX_C_SOURCE seems like it was done for some reason  in
  the past that may or may not be true and is causing trouble.   I would
  just remove it, and if it's needed in some particular situation, add
  it only in that situation, with a huge comment explaining.


I dropped the define of _POSIX_C_SOURCE from configure (by patching
configure), and that resulted in the build succeeding and the packaging
step failing with the following, which is glorious -- basically "gdt has
not updated the list of installed files to cover the improvements in
5.3.5-pre1"!

  => Checking file-check results for gutenprint-lib-5.3.5-pre1nb31
  ERROR: ************************************************************
  ERROR: The following files are in /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg but not in the PLIST:
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/libexec/cups/filter/commandtodyesub
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/5.3/xml/escp2/inks/pro_ultrachrome_d6s.xml
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/5.3/xml/escp2/inputslots/cutter_roll_only.xml
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/5.3/xml/escp2/media/pro_ultrachrome_d6s.xml
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/5.3/xml/escp2/model/model_136.xml
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/5.3/xml/escp2/qualitypresets/surelab.xml
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/a2128.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/book1.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/c1723.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/c193.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/c1974.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/c199.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/c38.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/c463.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/c47.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/f14.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/ln10.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/x1675.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/x1740.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/x2159.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/x270.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/x66.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/x78.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/gutenprint/doc/reference-html/x961.html
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/locale/hr/LC_MESSAGES/gutenprint.mo
  ERROR:         /tmp/work/print/gutenprint-lib/work/.destdir/usr/pkg/share/locale/hr/gutenprint_hr.po

I ran make check, and it passed ppds and is still going.
I don't have an inkjet printer any more, but from my viewpoint the only
thing wrong is the POSIX_C_SOURCE define.

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

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

> On Jul 10, 2024, at 12:54 PM, Greg Troxel <gd...@le...> wrote:
> 
> Matt Broughton <wal...@ma...> writes:
> 
>> FWIW, on macos 12.7.5, I do have to edit the `configure` line 19887
>> and delete '-D_POSIX_C_SOURCE=200809L -std=c99' to get v5.3.5-pre1 to
>> build.  If left in, the build will fail with errors of the type:
> 
> That's very interesting you see the same error on macOS as what I am
> seeing on NetBSD (but I hear that apple adopted NetBSD's networking
> stack and this is pbobably very longstanding code).
> 
> That is great progress to get it to build.  Did you, or could you, try
> with removing the -DPOSIX_C_SOURCE=200809L, and leaving --std=c99?   I
> am guessing that will be ok.
> 
> Visibility defines are tricky.  While they appear to say "make
> everything required by this standard visible", they really are "make
> *only* what this standard requires visible".  Many things in an OS are
> removed from visibility by them.
> 
> I wonder why that define exists in the first place.  Normally programs
> expect the posix+local-os environment, and that's almost always ok.
> 
> I believe that there are some systems that make an older standard
> available by default, and you have to ask for something more modern.
> Then, one would have to have defines to not only have the modern posix,
> but also turn back on the OS extensions that are expected, all ifdef'd
> on the OS that needs it.
> 

It does build fine on macos 12.7.5 with -std=c99.  I was going on what the previous macos maintainer indicated needed to be changed.  I am wondering if the macos builds ever used -std=c99.  Comparing the default v5.2.15 and v5.3.5-pre1 `configure` and the resulting Configuration Summary, I get:

v5.2.15
configure line 18503 ---
 'for stp_ac_arg in -D_POSIX_C_SOURCE=200809L -std=c99 -pedantic -Waggregate-return -Wcast-qual -Wshadow -Wredundant-decls ; do'

Configuration Summary---
 General configuration:
    Compiler options:                           -Disfinite=finite  -O6 -mmacosx-version-min=10.7 -Os -arch x86_64 -D_PPD_DEPRECATED=""  -Wall -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wwrite-strings -Werror-implicit-function-declaration -Winline -Wformat=2 -finline-limit=131072
    Build static libraries:                     yes
    Build shared libraries:                     yes
    Maintainer mode:                            no
    Use i18n:                                   no
    Generate profiling information:             no
    Generate debugging symbols:                 no
    Use modules:                                static
    Use readline libraries:                     yes, extra arguments: -lncurses
    uname -a output:                            Darwin Borodin.local 21.6.0 Darwin Kernel Version 21.6.0: Wed Apr 24 06:02:02 PDT 2024; root:xnu-8020.240.18.708.4~1/RELEASE_X86_64 x86_64
================================================================


v5.3.5-pre1
configure line19887---
  for stp_ac_arg in -Wall -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wwrite-strings -Werror-implicit-function-declaration -Winline -Wformat=2 -finline-limit=131072 -Wformat -Werror=format-security -D_POSIX_C_SOURCE=200809L -std=c99 ; do

Configuration Summary---
  General configuration:
    Configure arguments:                        --prefix=/Library/Printers/Gutenprint.printerDriver/Contents/MacOS --datadir=/Library/Printers/Gutenprint.printerDriver/Contents/Resources --datarootdir=/Library/Printers/Gutenprint.printerDriver/Contents/Resources --localedir=/Library/Printers/Gutenprint.printerDriver/Contents/Resources --docdir=/Library/Printers/Gutenprint.printerDriver/Contents/Resources/doc --mandir=/Library/Printers/Gutenprint.printerDriver/Contents/Resources --disable-samples --disable-test --enable-nls-macosx '--with-archflags=-mmacosx-version-min=10.7 -Os -arch x86_64 -D_PPD_DEPRECATED=""'
    Compiler:                                   gcc
    Compiler Version:                           Apple clang version 14.0.0 (clang-1400.0.29.202)
    Compiler options:                           -Disfinite=finite  -O3 -mmacosx-version-min=10.7 -Os -arch x86_64 -D_PPD_DEPRECATED=""  -Wformat -Werror=format-security -D_POSIX_C_SOURCE=200809L -std=c99
    Build static libraries:                     yes
    Build shared libraries:                     yes
    Maintainer mode:                            no
    Use i18n:                                   no
    Generate profiling information:             no
    Generate debugging symbols:                 no
    Use modules:                                static
    Use readline libraries:                     yes, extra arguments: -lncurses
    uname -a output:                            Darwin Borodin.local 21.6.0 Darwin Kernel Version 21.6.0: Wed Apr 24 06:02:02 PDT 2024; root:xnu-8020.240.18.708.4~1/RELEASE_X86_64 x86_64
================================================================


Both results are using macos 12.7.5 and the same XCode.  For some reason, the past 'configure' drops the compiler options '-D_POSIX_C_SOURCE=200809L -std=c99'.  The 'configure' keeps them as options.  There must be some differences in 'configure' between the two Gutenprint releases -- something that removes these options as not useable.  I wish I knew what I was doing.

Matt

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

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

On Wed, Jul 10, 2024 at 01:54:56PM -0400, Greg Troxel wrote:
> That is great progress to get it to build.  Did you, or could you, try
> with removing the -DPOSIX_C_SOURCE=200809L, and leaving --std=c99?   I
> am guessing that will be ok.

We definitely need --std=c99, as the codebase increasingly uses c99-isms 
and we don't know the defaults of whatever compiler is being used.

-DPOSIX_C_SOURCE=200809L is used to pull in strdup(), which is not part 
of the c99 stdlib but is required by POSIX.  This is on glibc at least, 
the BSDs and MacOS clearly differ.  

The manpage on Linux says -D_XOPEN_SOURCE >= 500 would also work, but I 
don't know what other side effects that might have.

Wihtout --std=c99, GCC likely defualts to 'gnuXX' (where XX depends on 
the exact version of the compiler) which defines _GNU_SOURCE and in 
turn also pulls in strdup().

..Hilariously, we already have a stp_strdup() function for this exact 
reason.

That said, there's also localtime_r (which also relies on POSIX_SOURCE 
and maybe BSD_SOURCE) and possibly some other stuff too.

 - 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] Gutenprint 5.3.5-pre1 Release

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

Matt Broughton <wal...@ma...> writes:

> FWIW, on macos 12.7.5, I do have to edit the `configure` line 19887
> and delete '-D_POSIX_C_SOURCE=200809L -std=c99' to get v5.3.5-pre1 to
> build.  If left in, the build will fail with errors of the type:

That's very interesting you see the same error on macOS as what I am
seeing on NetBSD (but I hear that apple adopted NetBSD's networking
stack and this is pbobably very longstanding code).

That is great progress to get it to build.  Did you, or could you, try
with removing the -DPOSIX_C_SOURCE=200809L, and leaving --std=c99?   I
am guessing that will be ok.

Visibility defines are tricky.  While they appear to say "make
everything required by this standard visible", they really are "make
*only* what this standard requires visible".  Many things in an OS are
removed from visibility by them.

I wonder why that define exists in the first place.  Normally programs
expect the posix+local-os environment, and that's almost always ok.

I believe that there are some systems that make an older standard
available by default, and you have to ask for something more modern.
Then, one would have to have defines to not only have the modern posix,
but also turn back on the OS extensions that are expected, all ifdef'd
on the OS that needs it.

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

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

> On Jul 9, 2024, at 6:49 PM, Greg Troxel <gd...@le...> wrote:
> 
> Solomon Peachy via Gimp-print-devel
> <gim...@li...> writes:
> 
>> Gutenprint 5.3.5-pre1 is a prerelease of Gutenprint 5.3.5.  
> 
........

>>  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.
> 
> I'm hoping that a posix-type build on macos is ok, but if not we can
> mark the pkgsrc package BROKEN.

FWIW, on macos 12.7.5, I do have to edit the `configure` line 19887 and delete '-D_POSIX_C_SOURCE=200809L -std=c99' to get v5.3.5-pre1 to build.  If left in, the build will fail with errors of the type:

In file included from gutenprint.c:40:
In file included from ./genppd.h:56:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/cups/raster.h:20:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/cups/cups.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/cups/ipp.h:18:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/cups/http.h:39:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:86:2: error: unknown type name 'u_int'
        u_int   ip_hl:4,                /* header length */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:90:2: error: unknown type name 'u_int'
        u_int   ip_v:4,                 /* version */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:90:10: error: duplicate member 'ip_v'
        u_int   ip_v:4,                 /* version */
                ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:87:6: note: previous declaration is here
            ip_v:4;                     /* version */
            ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:91:6: error: duplicate member 'ip_hl'
            ip_hl:4;                    /* header length */
            ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:86:10: note: previous declaration is here
        u_int   ip_hl:4,                /* header length */
                ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:94:2: error: unknown type name 'u_char'; did you mean 'char'?
        u_char  ip_tos;                 /* type of service */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/ip.h:95:2: error: unknown type name 'u_short'; did you mean 'n_short'?
        u_short ip_len;                 /* total length */
        ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/netinet/in_systm.h:84:20: note: 'n_short' declared here
typedef __uint16_t n_short;             /* short as received from the net */
                   ^

Full configure and build available if desired.

This problem seems to have come up beginning with v5.3.4.  That is when it started to appear in the Configuration Summary.  In v5.3.3 and prior,  '-D_POSIX_C_SOURCE=200809L -std=c99' was never part of the compiler flags in the Configuration Summary.  I have not done any testing of the v5.3.5-pre1 build itself.

Matt

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

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

Thanks, 

I will twiddle knobs when I have the time and see if I can back myself into clarity.

warmest
-Walker



> On Jul 9, 2024, at 8:41 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Mon, Jul 01, 2024 at 03:00:49PM -0400, Walker Blackwell wrote:
>> I can follow 60% of this . . .
> 
> When it comes to this stuff, I feel like the one-eyed king leading the 
> blind.  :(
> 
>> 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.
> 
> I _think_ what happens here is that it works out the common K between 
> the channels, then uses a (non-linear) lookup table (and the color 
> balance knobs) to figure the corresponding amount to reduce each channel 
> by.
> 
>> Maybe ideally I’m simply saying for the color outputs that it’s 1 * 
>> cg->color_balance. ?
> 
> That sounds logical, but I've never sufficiently immersed myself in 
> gutenprint's core color channel stuff to truly understand it, and I'm 
> embarassed to say I've probably forogotten 89.3% of what I managed to 
> absorb the last time around.
> 
> - 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

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

On Mon, Jul 01, 2024 at 03:00:49PM -0400, Walker Blackwell wrote:
> I can follow 60% of this . . .

When it comes to this stuff, I feel like the one-eyed king leading the 
blind.  :(
 
> 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.

I _think_ what happens here is that it works out the common K between 
the channels, then uses a (non-linear) lookup table (and the color 
balance knobs) to figure the corresponding amount to reduce each channel 
by.

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

That sounds logical, but I've never sufficiently immersed myself in 
gutenprint's core color channel stuff to truly understand it, and I'm 
embarassed to say I've probably forogotten 89.3% of what I managed to 
absorb the last time around.

 - 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] Gutenprint 5.3.5-pre1 Release

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

On Tue, Jul 09, 2024 at 07:49:34PM -0400, Greg Troxel wrote:
> This really seems buggy of sourceforge, and seems to be hostile to
> packaging.  I am guessing this is just how it is, and there's not much
> to be done, other than skipping github and moving to codeberg :-)

I'd probably jump straight to sourcehut instead, because I prefer email.

...just have to get this release out the door before I can figure out 
what to do next.  I'd rather self-host than stay on sourceforge.

> I am curious if other packagers also find this troublesome.  They might
> well not; this is just a collision between pkgsrc assuming
> near-universal practice and sourceforge being odd.

I honestly don't know.
 
> >   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.
> 
> I'm hoping that a posix-type build on macos is ok, but if not we can
> mark the pkgsrc package BROKEN.

Given that we have to integrate with the MacOS printing subsystem and 
directly speak to attached USB devices, I don't believe a posix-type 
build has been sufficient for something like a decade..

 - 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] Improve print quality of Citizen CX-02

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

On Tue, Jul 09, 2024 at 08:39:54PM +0200, Foto-Stoelzle wrote:
>    When using Gutenprint, the colour is darker (more orange instead of
>    gold) and straight lines are pixelated.

First, you didn't mention what version of Gutenprint you're using.  If 
it's older than 5.3.4, then you should update as previous versions use 
the wrong gamma curve for all dye-sublimation models.

Second, are you using using Citizen's ICC profile as part of a 
color-corrected work/print flow?  If not, there is no objective basis 
for comparing the color output between Windows and Linux.

As for the jagged pixels, that's most likely due to low-quality image 
scaling.  It is always best to pre-scale the image you are printing to 
the printer's native resolution at the application layer; that way you 
have full control over how that is done.

My personal print flow uses a script to:

 * Set printer options to default to completely neutral output
 * Scale to native printer resolution
 * Apply sharpening pass
 * Apply printer ICC profile
 * Submit to printer

I do things this way to ensure I get consistent output no matter which 
of several printers is used for a particular print.

 - 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] Gutenprint 5.3.5-pre1 Release

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

in src/cups/gutenprint.c, *before the first include*, I added:

#if LITTLE_ENDIAN == BIG_ENDIAN
#error LITTLEBIG
#endif

and then

  gmake[3]: Entering directory '/tmp/work/print/gutenprint-lib/work/gutenprint-5.3.5-pre1/src/cups'
  ""gcc -DHAVE_CONFIG_H -I. -I../..  -I../../include -I../../include  -I/usr/pkg/include -DBASE_VERSION=\"5.3.5\" -DSBINDIR=\"/usr/pkg/sbin/\" -Wall -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wwrite-strings -Werror-implicit-function-declaration -Winline -Wformat=2 -finline-limit=131072 -Wformat -Werror=format-security -D_POSIX_C_SOURCE=200809L -std=c99 -DPACKAGE_LOCALE_DIR=\"/usr/pkg/share/locale\" -DPACKAGE_DATA_DIR=\"/usr/pkg/share/gutenprint\" -DPACKAGE_LIB_DIR=\"/usr/pkg/lib/gutenprint\" -DPACKAGE_BIN_DIR=\"/usr/pkg/bin\" -DPKGMODULEDIR=\"/usr/pkg/lib/gutenprint/5.3/modules\" -DPKGXMLDATADIR=\"/usr/pkg/share/gutenprint/5.3/xml\" -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/include/krb5 -DALL_LINGUAS='"ca cs da de el en_GB es fi fr gl hr hu it ja nb nl pl pt ru sk sl sv tr uk vi zh_CN zh_TW"'   -Disfinite=finite -O2 -I/usr/pkg/include -I/usr/include -I/usr/X11R7/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/include/krb5 -O3 -MT gutenprint_5.3-gutenprint.o -MD -MP -MF .deps/gutenprint_5.3-gutenprint.Tpo -c -o gutenprint_5.3-gutenprint.o `test -f 'gutenprint.c' || echo './'`gutenprint.c
  gutenprint.c:41:2: error: #error LITTLEBIG
     41 | #error LITTLEBIG
        |  ^~~~~

but I can't see it as -D on the build line, and the if/error is literally right
after the comments before the include of genppd.h.   So I can't see
where it is coming from, unless gnu11 does something?

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

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

I'm building on NetBSD 10 amd64.

Building this is going much better than my memory of 5.3.4 (which I'm
happy to ignore as superceded; I am seeing pre1 as sort of alpha, maybe
before, to head to a release).  But it may be exactly the same and I
gave up earlier, even though this seems obviously fairly easy to resolve.

I was able to drop multiple patches that removed bashisms (test ==, test
[[), some of which I reported long ago and some of which I probably
didn't.  I'm so far down to 1 patch to find lpstat where pkgsrc puts it.

I noticed configure looking for gnu11.  I can't find in README where
this is described, or if it's new.

Most of the build was fine, and not even any warnings.

There are a bunch of gtk deprecation warnings, but I'm guessing they are
well known.  If not happy to extract and send them.

I have residual compile failures (make -k after previous make -k), and
it looks like N instances of the same issue.

tldr: It seems like the system endian defines are being overwritten.
I'll look harder.

  gmake[3]: Entering directory '/tmp/work/print/gutenprint-lib/work/gutenprint-5.3.5-pre1/src/cups'
    CC       gutenprint_5.3-gutenprint.o
  In file included from /tmp/work/print/gutenprint-lib/work/.buildlink/include/cups/http.h:40,
                   from /tmp/work/print/gutenprint-lib/work/.buildlink/include/cups/ipp.h:19,
                   from /tmp/work/print/gutenprint-lib/work/.buildlink/include/cups/cups.h:28,
                   from /tmp/work/print/gutenprint-lib/work/.buildlink/include/cups/raster.h:21,
                   from genppd.h:56,
                   from gutenprint.c:40:
  /usr/include/netinet/ip.h:57:15: error: duplicate member 'ip_v'
     57 |  unsigned int ip_v:4,  /* version */
        |               ^~~~
  /usr/include/netinet/ip.h:58:8: error: duplicate member 'ip_hl'
     58 |        ip_hl:4;  /* header length */
        |        ^~~~~
  /usr/include/netinet/ip.h:202:15: error: duplicate member 'ipt_oflw'
    202 |  unsigned int ipt_oflw:4, /* overflow counter */
        |               ^~~~~~~~
  /usr/include/netinet/ip.h:203:8: error: duplicate member 'ipt_flg'
    203 |        ipt_flg:4;  /* flags, see below */
        |        ^~~~~~~
  In file included from /usr/include/stddef.h:37,
                   from ../../include/gutenprint/gutenprint.h:44,
                   from i18n.h:20,
                   from genppd.h:36,
                   from gutenprint.c:40:
  /usr/include/netinet/ip.h:252:1: error: negative width in bit-field '__ctassert1'
    252 | __CTASSERT(sizeof(struct ip) == 20);
        | ^~~~~~~~~~
  /usr/include/netinet/ip.h:253:1: error: negative width in bit-field '__ctassert2'
    253 | __CTASSERT(sizeof(struct ip_timestamp) == 12);
        | ^~~~~~~~~~
  gmake[3]: *** [Makefile:1619: gutenprint_5.3-gutenprint.o] Error 1


The header has

  struct ip {
  #if BYTE_ORDER == LITTLE_ENDIAN
          unsigned int ip_hl:4,           /* header length */
                       ip_v:4;            /* version */
  #endif
  #if BYTE_ORDER == BIG_ENDIAN
          unsigned int ip_v:4,            /* version */
                       ip_hl:4;           /* header length */
  #endif

so I wonder if LITTLE_ENDIAN and BIG_ENDIAN are getting defined to the
the same.

On NetBSD (and perhaps other bsd):

  /usr/include/sys/endian.h:#define       LITTLE_ENDIAN   1234            /* LSB first: i386, vax */
  /usr/include/sys/endian.h:#define       BIG_ENDIAN      4321            /* MSB first: 68000, ibm, net */

and this is included by sys/types.h.

Any clues appreciated.

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

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

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

> Gutenprint 5.3.5-pre1 is a prerelease of Gutenprint 5.3.5.  

I maintain the entry for gutenprint in pkgsrc, but have been less active
lately.  pkgsrc is at 5.3.3, because my attempt to update to 5.3.4 was
not successful, but I did not get to the point of a bug report tht would
be worth your time.

> 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

This is a very awkward URL for us.   pkgsrc expects packages to have the
following which are concatenated, with the 5.3.3 values shown and their expansion

  MASTER_SITES		${MASTER_SITE_SOURCEFORGE:=gimp-print/}
                        https://downloads.sourceforge.net/sourceforge/gimp-print/

  DISTNAME		gutenprint-5.3.3

  EXTRACT_SUFx          .tar.xz

I edited DISTNAME to be gutenprint-5.3.5pre1 and the requested file was

  https://downloads.sourceforge.net/sourceforge/gimp-print/gutenprint-5.3.5.pre.tar.xz

which isn't what you sent ;-)   With my browser I found clicking from
files exactly what you sent.

  https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.5-pre1/gutenprint-5.3.5-pre1.tar.xz/download

This really seems buggy of sourceforge, and seems to be hostile to
packaging.  I am guessing this is just how it is, and there's not much
to be done, other than skipping github and moving to codeberg :-)

> 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.

Thanks for doing this.  I don't mean to sound super grumpy and am hoping
my comments are helfpul.  I'll work around this, and it may be easier to
host a distfile copy on ftp.netbsd.org than to teach pkgsrc to put the
EXTRACT_SUFX not at the end.

I am curious if other packagers also find this troublesome.  They might
well not; this is just a collision between pkgsrc assuming
near-universal practice and sourceforge being odd.

>   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.

I'm hoping that a posix-type build on macos is ok, but if not we can
mark the pkgsrc package BROKEN.

Re: [Gimp-print-devel] Bug report #741 Canon PIXMA iP7260 CD print alignment

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

On Wed, Jul 10, 2024 at 10:31:16AM +1200, Grant Pearson wrote:
> Can the patches I made to fix bug report #741 "Canon PIXMA iP7260 CD print
> alignment" please be incorporated into release 5.3.5

Sure, that seems to be a reasonable (and necessary) change.

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

[Gimp-print-devel] Bug report #741 Canon PIXMA iP7260 CD print alignment

[Grant P. <gra...@xt...>]

Hi Solomon,

Can the patches I made to fix bug report #741 "Canon PIXMA iP7260 CD 
print alignment" please be incorporated into release 5.3.5

The patch is:

I have successfully printed to CD by updated the range for CDXAdjustment 
& CDYAdjustment in:
./src/main/print-canon.c

lines 334-339 (correct text):
{
"CDYAdjustment", N_("CD Vertical Fine Adjustment"), 
"Color=No,Category=Advanced Printer Setup",
N_("Fine adjustment to vertical position for CD printing"),
STP_PARAMETER_TYPE_DIMENSION, STP_PARAMETER_CLASS_FEATURE,
STP_PARAMETER_LEVEL_ADVANCED, 1, 1, STP_CHANNEL_NONE, 1, 0
},

lines 2950-2961 (increase range from -15 - +15 to -250 - +250:
else if (strcmp(name, "CDXAdjustment") == 0 ||
strcmp(name, "CDYAdjustment") == 0)
{
const char* input_slot = stp_get_string_parameter(v, "InputSlot");
description->bounds.dimension.lower = -250;
description->bounds.dimension.upper = 250;
description->deflt.dimension = 0;
if (!input_slot || !strcmp(input_slot,"CD"))
description->is_active = 1;
else
description->is_active = 0;
}

I also increased the range in the corresponding Pixma iP8760.PPD file 
(and the value for DefaultStpCDYAdjustment =125 for correct printing on 
Pixma iP8760) .

Thanks
Grant

[Gimp-print-devel] Improve print quality of Citizen CX-02

[Foto-Stoelzle <in...@fo...>]

<div dir='auto'><div>Hi all,</div><div dir="auto"><br></div><div dir="auto">First of all, thanks for all your work!</div><div dir="auto">I'mm using a Citizen CX-02 dye-sublimation printer. The quality when printing using the corresponding Gutenprint driver is not as good as it is when using the manufacturers driver on windows.</div><div dir="auto">Would you be interested in improving the print quality (if possible)? I'd be glad to help.</div><div dir="auto"><br></div><div dir="auto">Attached you can find the differences:</div><div dir="auto">When using Gutenprint, the colour is darker (more orange instead of gold) and straight lines are pixelated.</div><div dir="auto"><br></div><div dir="auto">Regards Kevin</div><div><br></div></div>

[Gimp-print-devel] Raspberry 4 & Canon Selphy1500

[<ino...@we...>]

Guten Tag,
Ich habe einen Raspberry 4, einen Canon Selphy1500 und Gutenprint installiert.

Leider wird mit der Drucker Canon Selphy1500 bei gutenprint über 172.0.0.1:631 unter Drucker hinzufügen nicht angezeigt.

Haben Sie diesbezüglich schon Informationen bzw. Erfolgreiche tests ?
Ich habe die Frage mal parallel im deutschen Raspberry Forum plaziert und wart dort auch mal, ob sich jemand da schon heranbegeben hat.

Vielen Dank für ein Feedback Ihrerseits.

Lieben Gruß Ino Ecker