gimp-print-devel

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

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

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

Gutenprint 5.3.5-pre1 is a prerelease of Gutenprint 5.3.5.  

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

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

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

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

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

Notable changes from 5.3.4:

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

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

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

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

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

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

  4) Added support for the following inkjet printer models:

     Epson SureLab D700
     Fujifilm DX100

  5) Added support for the following laser printer models:

     Sharp MX-2600N

  6) Various minor fixes and enhancements

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

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

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

I can follow 60% of this . . .

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

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

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

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

Would this output a more dumbed down thing?

best
-Walker




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

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

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

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

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

This is its main loop:

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



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

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

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

Dear Gutenprint community,

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

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

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

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

warmest,
-Walker

[Gimp-print-devel] Brother MFC 9142 CDN

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

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


Mit freundlichen Grüßen
Klaus-Dieter Seeber


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

DL6KDS

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

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

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

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

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

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

With unidirectional printing, this effect disappears.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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