gimp-print-devel

Re: [Gimp-print-devel] libgutenprint versions macos

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

On Sun, Aug 11, 2024 at 02:27:41PM -0500, Matt Broughton wrote:
> Building v5.3.5-pre1, I get libgutenprint.8.dylib.  This seems odd to me as v5.3.3, produces libgutenprint.9.dylib.  Seemingly a higher version.  Is this correct? 
> When I run otool -L, the versioning seems logical with 
> v5.3.5-pre1  ----- otool -L libgutenprint8.dylib shows a current version 15.0.0
> v5.3.3      -------- otool -L libgutenprint.9.dylib shows a current version 14.0.0

Hmm, I see what's going on.  And yes, it's a mistake on my part.

(What threw me off is that Gutenprint doesn't use standard 3-component 
libtool version naming conventions, due to unspecified MacOS issues..)

I'll probably spin a -pre2 tonight, to pull this (and a bunch of other 
fixes) in.

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

[Gimp-print-devel] libgutenprint versions macos

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

Building v5.3.5-pre1, I get libgutenprint.8.dylib.  This seems odd to me as v5.3.3, produces libgutenprint.9.dylib.  Seemingly a higher version.  Is this correct? 

When I run otool -L, the versioning seems logical with 
v5.3.5-pre1  ----- otool -L libgutenprint8.dylib shows a current version 15.0.0
v5.3.3      -------- otool -L libgutenprint.9.dylib shows a current version 14.0.0

Everything is working fine, it was just a bit odd to see a lower number for libgutenprint.x.dylib.

Matt

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

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

> On Aug 9, 2024, at 11:10 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Aug 9, 2024, at 8:42 PM, Michael Sweet <ms...@ms...> wrote:
>> 
>> Matt,
>> 
>>> On Aug 9, 2024, at 9:21 PM, Matt Broughton <wal...@ma...> wrote:
>>> ...
>>> Thank you for your help Michael.  Unfortunately, I still can't get it to build all the way.
>>> 
>>> I did as you said for building libusb and installed --
>> 
>> Hmm, maybe edit the installed libusb-1.0.pc to include the Libs.private on the end of the regular Libs, like this:
>> 
>>   Libs: -L${libdir} -lusb-1.0 -lobjc -Wl,-framework,IOKit -Wl,-framework,CoreFoundation
> 
> Almost.  You also need to add -Wl,-framework,Security which then matches Libs private.
> 
> Libs: -L${libdir} -lusb-1.0 -lobjc -Wl,-framework,IOKit -Wl,-framework,CoreFoundation -Wl,-framework,Security
> Libs.private:  -lobjc -Wl,-framework,IOKit -Wl,-framework,CoreFoundation -Wl,-framework,Security
> Cflags: -I${includedir}/libusb-1.0
> 
> Now it builds.  I haven't tested the build yet, but this is a big step.  Thank you Michael.

A quick follow on--- Everything now builds nicely and summary testing is without problems.  
1. After uninstalling  libsub, the 'gutenprint53+usb' backend works nicely for the one printer tested(sudo BACKEND=mitsu70x /usr/libexec/cups/backend/gutenprint53+usb -s).  
2. With the modifications to genppd.c cited earlier in the thread, all Printer Features are available for printers that can print to CD/DVDs and are passed properly for printing (tested using file print for Epson SP R800)
3. Actual ink on paper with Epson WF-1100 is fine.

I will do some more testing at a later time.

Matt

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

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

> On Aug 9, 2024, at 8:42 PM, Michael Sweet <ms...@ms...> wrote:
> 
> Matt,
> 
>> On Aug 9, 2024, at 9:21 PM, Matt Broughton <wal...@ma...> wrote:
>> ...
>> Thank you for your help Michael.  Unfortunately, I still can't get it to build all the way.
>> 
>> I did as you said for building libusb and installed --
> 
> Hmm, maybe edit the installed libusb-1.0.pc to include the Libs.private on the end of the regular Libs, like this:
> 
>    Libs: -L${libdir} -lusb-1.0 -lobjc -Wl,-framework,IOKit -Wl,-framework,CoreFoundation

Almost.  You also need to add -Wl,-framework,Security which then matches Libs private.

Libs: -L${libdir} -lusb-1.0 -lobjc -Wl,-framework,IOKit -Wl,-framework,CoreFoundation -Wl,-framework,Security
Libs.private:  -lobjc -Wl,-framework,IOKit -Wl,-framework,CoreFoundation -Wl,-framework,Security
Cflags: -I${includedir}/libusb-1.0

Now it builds.  I haven't tested the build yet, but this is a big step.  Thank you Michael.

Matt

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

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

Matt,

> On Aug 9, 2024, at 9:21 PM, Matt Broughton <wal...@ma...> wrote:
> ...
> Thank you for your help Michael.  Unfortunately, I still can't get it to build all the way.
> 
> I did as you said for building libusb and installed --

Hmm, maybe edit the installed libusb-1.0.pc to include the Libs.private on the end of the regular Libs, like this:

    Libs: -L${libdir} -lusb-1.0 -lobjc -Wl,-framework,IOKit -Wl,-framework,CoreFoundation

________________________
Michael Sweet

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

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

> On Aug 9, 2024, at 6:55 AM, Michael Sweet via Gimp-print-devel <gim...@li...> wrote:
> 
> Matt,
> 
>> On Aug 8, 2024, at 4:01 PM, Matt Broughton <wal...@ma...> wrote:
>> ...
>> libusb is not included with any version of macos. What I am tyring to do is make an installer package for Gutenprint where gutenprint53+usb will work without having the macos Gutenprint installer actually installing libusb--  to build a statically linked binary or library.
> 
> So I actually do this for my LPrint and hp-printer-app packages on macOS, which depend on PAPPL and libusb.
> 
> The libusb configure script supports the "--disable-shared" option.  Use it and then it will only link statically to libusb.
> 
> I also set the compiler flags before running the configure script as follows to build "fat" for macOS 11 and later:
> 
>    CFLAGS="-mmacosx-version-min=11.0 -arch x86_64 -arch arm64"; export CFLAGS
>    CXXFLAGS="-mmacosx-version-min=11.0 -arch x86_64 -arch arm64"; export CXXFLAGS
>    LDFLAGS="-mmacosx-version-min=11.0 -arch x86_64 -arch arm64"; export LDFLAGS
> 
> You can change the min version to whatever you like, although the code signing and notarization stuff changed between macOS 10.13 and 10.14 so I personally wouldn't go any older than 10.14...  If you decide to do a PPC-compatible build then you'll need an older system and use "-arch i386 -arch ppc" in the compiler options.

Thank you for your help Michael.  Unfortunately, I still can't get it to build all the way.

I did as you said for building libusb and installed --

matt$ file /usr/local/lib/libusb-1.0.a 
/usr/local/lib/libusb-1.0.a: Mach-O universal binary with 2 architectures: [x86_64:current ar archive random library] [arm64:current ar archive random library]
/usr/local/lib/libusb-1.0.a (for architecture x86_64):	current ar archive random library
/usr/local/lib/libusb-1.0.a (for architecture arm64):	current ar archive random library
matt$ lipo -archs /usr/local/lib/libusb-1.0.a 
x86_64 arm64

Then I went to build gutenprint 5.3.5-pre1 fat(x86_64 and arm64), and it errored out building the backend.  Interestingly, if I switch the architecture around (arm64 and x86_64), it will fail with the same error but show capture_entitlements in libusb-1.0a[arm64].......   I went back and built and installed libusb for only arm64.  Same errors when I go to build gutennprint backend.

Undefined symbols for architecture x86_64:
  "_SecTaskCopyValueForEntitlement", referenced from:
      _darwin_has_capture_entitlements in libusb-1.0.a[x86_64][10](darwin_usb.o)
  "_SecTaskCreateFromSelf", referenced from:
      _darwin_has_capture_entitlements in libusb-1.0.a[x86_64][10](darwin_usb.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [backend_gutenprint] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

When run with "-v" added to LDFLAGS ---

Making all in cups
  CC       cups-calibrate.o
  CCLD     cups-calibrate
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -platform_version macos 11.0.0 14.5 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -Os -o /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/cups-calibrate-835523/cups-calibrate-x86_64.out -L/usr/local/lib cups-calibrate.o -lm -framework IOKit -framework CoreFoundation -arch_multiple -final_output cups-calibrate -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch arm64 -platform_version macos 11.0.0 14.5 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -Os -o /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/cups-calibrate-104106/cups-calibrate-arm64.out -L/usr/local/lib cups-calibrate.o -lm -framework IOKit -framework CoreFoundation -arch_multiple -final_output cups-calibrate -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo" -create -output cups-calibrate /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/cups-calibrate-835523/cups-calibrate-x86_64.out /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/cups-calibrate-104106/cups-calibrate-arm64.out
  CC       backend_gutenprint-backend_canonselphy.o
  CC       backend_gutenprint-backend_canonselphyneo.o
  CC       backend_gutenprint-backend_kodak1400.o
  CC       backend_gutenprint-backend_kodak6800.o
  CC       backend_gutenprint-backend_kodak605.o
  CC       backend_gutenprint-backend_shinkos2145.o
  CC       backend_gutenprint-backend_sonyupd.o
  CC       backend_gutenprint-backend_sonyupdneo.o
  CC       backend_gutenprint-backend_dnpds40.o
  CC       backend_gutenprint-backend_mitsu70x.o
  CC       backend_gutenprint-backend_mitsu9550.o
  CC       backend_gutenprint-backend_sinfonia.o
  CC       backend_gutenprint-backend_common.o
  CC       backend_gutenprint-backend_shinkos1245.o
  CC       backend_gutenprint-backend_shinkos6145.o
  CC       backend_gutenprint-backend_shinkos6245.o
  CC       backend_gutenprint-backend_mitsup95d.o
  CC       backend_gutenprint-backend_magicard.o
  CC       backend_gutenprint-backend_mitsud90.o
  CC       backend_gutenprint-backend_hiti.o
  CC       backend_gutenprint-backend_mitsu.o
  CC       backend_gutenprint-backend_kodak8800.o
  CCLD     backend_gutenprint
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -platform_version macos 11.0.0 14.5 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -Os -o /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/backend_gutenprint-backend_canonselphy-7e07f3/backend_gutenprint-backend_canonselphy-x86_64.out -L/usr/local/lib -L/usr/local/lib backend_gutenprint-backend_canonselphy.o backend_gutenprint-backend_canonselphyneo.o backend_gutenprint-backend_kodak1400.o backend_gutenprint-backend_kodak6800.o backend_gutenprint-backend_kodak605.o backend_gutenprint-backend_shinkos2145.o backend_gutenprint-backend_sonyupd.o backend_gutenprint-backend_sonyupdneo.o backend_gutenprint-backend_dnpds40.o backend_gutenprint-backend_mitsu70x.o backend_gutenprint-backend_mitsu9550.o backend_gutenprint-backend_sinfonia.o backend_gutenprint-backend_common.o backend_gutenprint-backend_shinkos1245.o backend_gutenprint-backend_shinkos6145.o backend_gutenprint-backend_shinkos6245.o backend_gutenprint-backend_mitsup95d.o backend_gutenprint-backend_magicard.o backend_gutenprint-backend_mitsud90.o backend_gutenprint-backend_hiti.o backend_gutenprint-backend_mitsu.o backend_gutenprint-backend_kodak8800.o /usr/local/lib/libusb-1.0.a -lobjc -ldl -framework IOKit -framework CoreFoundation -arch_multiple -final_output backend_gutenprint -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
  "_SecTaskCopyValueForEntitlement", referenced from:
      _darwin_has_capture_entitlements in libusb-1.0.a[x86_64][10](darwin_usb.o)
  "_SecTaskCreateFromSelf", referenced from:
      _darwin_has_capture_entitlements in libusb-1.0.a[x86_64][10](darwin_usb.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [backend_gutenprint] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


> 
> If it would be useful, I'm happy to share my (currently private) "macbase" project which I use to build a couple dozen common tools and libraries on my Macs, all using static libraries and "fat".

Thank you for your offer.  I think most of it would be over my head and lost on me.  I'll play around with libusb and gutenprint a bit more.  If nothing else, I can at least test the v5.3.5-pre1 release and update the build script and uninstaller.

Matt

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

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

Matt,

> On Aug 8, 2024, at 4:01 PM, Matt Broughton <wal...@ma...> wrote:
> ...
> libusb is not included with any version of macos. What I am tyring to do is make an installer package for Gutenprint where gutenprint53+usb will work without having the macos Gutenprint installer actually installing libusb--  to build a statically linked binary or library.

So I actually do this for my LPrint and hp-printer-app packages on macOS, which depend on PAPPL and libusb.

The libusb configure script supports the "--disable-shared" option.  Use it and then it will only link statically to libusb.

I also set the compiler flags before running the configure script as follows to build "fat" for macOS 11 and later:

    CFLAGS="-mmacosx-version-min=11.0 -arch x86_64 -arch arm64"; export CFLAGS
    CXXFLAGS="-mmacosx-version-min=11.0 -arch x86_64 -arch arm64"; export CXXFLAGS
    LDFLAGS="-mmacosx-version-min=11.0 -arch x86_64 -arch arm64"; export LDFLAGS

You can change the min version to whatever you like, although the code signing and notarization stuff changed between macOS 10.13 and 10.14 so I personally wouldn't go any older than 10.14...  If you decide to do a PPC-compatible build then you'll need an older system and use "-arch i386 -arch ppc" in the compiler options.

If it would be useful, I'm happy to share my (currently private) "macbase" project which I use to build a couple dozen common tools and libraries on my Macs, all using static libraries and "fat".

________________________
Michael Sweet

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

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

> On Aug 8, 2024, at 6:52 AM, Greg Troxel <gd...@le...> wrote:
> 
> Matt Broughton <wal...@ma...> writes:
> 
>>> On Aug 7, 2024, at 6:53 AM, Greg Troxel <gd...@le...> wrote:
>>> 
>>> Matt Broughton <wal...@ma...> writes:
>>> 
>>>> The third party package managers for macos are fink, mac ports, and
>>>> brew.  One of them might be interested.  I have used all three of them
>>>> at one point or another.
>>> 
>>> pkgsrc also builds for macos, among many others.
>> 
>> Thanks for the information Greg.  Somehow I missed that resource.
>> 
>> The nice thing about using a package manager for macos is that the
>> package maintainer will make sure that libusb is available.  All of
>> the existing macos v5.3.x packages break Solomon's backend because
>> libusb was not built against the static library.  My attempts to build
>> against a static libusb have failed.  From searching the web, there
>> seems to be little, if any, real support for building against static
>> libraries.
>> Matt
> 
> I am not quite following.  Are you trying to build a gutenprint dynamic
> library that has somehow included ilbusb?   I don't understand why you
> would need to do this, but I'm used to a world where all the instsalled
> libraries are ok.

Sorry about not being clear -- part stream of consciousness and part not fully knowing what I am doing.
 
libusb is not included with any version of macos. What I am tyring to do is make an installer package for Gutenprint where gutenprint53+usb will work without having the macos Gutenprint installer actually installing libusb--  to build a statically linked binary or library.

There are a couple of reasons for this.  1. I don't want to have to worry about license compatibility, distributing a copy of libusb license, source code etc.    2. The end user may already have libusb installed and I sure don't want to clobber it. Steps can be taken to get around this, but things get more complicated and the 'uninstaller' must also be updated carefully so that it only removes files and symlinks Gutennprint installed.

Matt

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

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

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

>> On Aug 7, 2024, at 6:53 AM, Greg Troxel <gd...@le...> wrote:
>> 
>> Matt Broughton <wal...@ma...> writes:
>> 
>>> The third party package managers for macos are fink, mac ports, and
>>> brew.  One of them might be interested.  I have used all three of them
>>> at one point or another.
>> 
>> pkgsrc also builds for macos, among many others.
>
> Thanks for the information Greg.  Somehow I missed that resource.
>
> The nice thing about using a package manager for macos is that the
> package maintainer will make sure that libusb is available.  All of
> the existing macos v5.3.x packages break Solomon's backend because
> libusb was not built against the static library.  My attempts to build
> against a static libusb have failed.  From searching the web, there
> seems to be little, if any, real support for building against static
> libraries.
> Matt

I am not quite following.  Are you trying to build a gutenprint dynamic
library that has somehow included ilbusb?   I don't understand why you
would need to do this, but I'm used to a world where all the instsalled
libraries are ok.

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

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

> On Aug 7, 2024, at 6:53 AM, Greg Troxel <gd...@le...> wrote:
> 
> Matt Broughton <wal...@ma...> writes:
> 
>> The third party package managers for macos are fink, mac ports, and
>> brew.  One of them might be interested.  I have used all three of them
>> at one point or another.
> 
> pkgsrc also builds for macos, among many others.

Thanks for the information Greg.  Somehow I missed that resource.

The nice thing about using a package manager for macos is that the package maintainer will make sure that libusb is available.  All of the existing macos v5.3.x packages break Solomon's backend because libusb was not built against the static library.  My attempts to build against a static libusb have failed.  From searching the web, there seems to be little, if any, real support for building against static libraries.
Matt

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

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

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

> The third party package managers for macos are fink, mac ports, and
> brew.  One of them might be interested.  I have used all three of them
> at one point or another.

pkgsrc also builds for macos, among many others.

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

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

> On Aug 6, 2024, at 4:11 PM, Solomon Peachy via Gimp-print-devel <gim...@li...> wrote:
> 
> On Tue, Aug 06, 2024 at 03:59:38PM -0500, Matt Broughton wrote:
>> At the least, the fix can be memorialized on the list.  The fix for 
>> macos is to do away with a custom option for printing on CD/DVDs.
> 
> The discussion was too long ago to jog my memory, but I'm not in favor 
> of killing this option for everyone because MacOS is um, differently abled. 
> 
>> When we found this fix, it was felt that the custom option was important to keep wherever possible.  Using something like 
>> #ifdef __APPLE__ 
>> was not favored, but nothing was ever resolved.  If genppd.c could be 
>> modified and a conditional #ifdef __APPLE__ addition, or something 
>> else) is palatable, it would be appreciated.  I'm not a coder, so I 
>> can't give the exact code needed.
> 
> Given a choice between "Completely broken on MacOS but works for 
> everyone else" and "disable this feature for MacOS and leave it enabled 
> for everyone else" I'm much in favor of the latter.
> 
> I do worry about the support requests, but I suppose this is the lest 
> crappy choice.

On macos, it completely breaks for any printer that is capable of printing to CD/DVD.  On various versions of macos, calling up Printer Features may, crash the app, or no Printer Features will appear.  In macos 14, only some of the Printer features appear.

> 
>> The v5.3.5-pre1 release does build nicely from the command line on 
>> machines of both architectures (macos 12.5 x86_64 and macos 14.5 
>> arm64).  The `make check` was took about 8 hours, but everything 
>> passed.
> 
> It builds, but does it... well, work with actual printers?  (And I'm 
> especially curious about the dyesub backend; integrating that required a 
> lot of headaches in the past)

It does work with my Epson WF-1100.  I may be able to  access a color Xerox Phaser to test the pcl driver. With the modification to genppd.c, the Epson R800 (which does print on CD/DVD) showed all the Printer Features and printed a file job usiing some custom settings.  I did run a test on just one dyesub printer and it works--
matt$ sudo BACKEND=mitsu70x /usr/libexec/cups/backend/gutenprint53+usb -s
Password:
DEBUG: Multi-Call Dye-sublimation CUPS Backend version 0.132G
DEBUG: Copyright 2007-2024 Solomon Peachy
DEBUG: This free software comes with ABSOLUTELY NO WARRANTY! 
DEBUG: Licensed under the GNU GPL.  Run with '-G' for more details.
DEBUG: 
STATE: +connecting-to-device
STATE: +org.gutenprint.searching-for-device
STATE: -org.gutenprint.searching-for-device
ERROR: Printer open failure (No matching printers found!)
STATE: +offline-report
STATE: -connecting-to-device

> If it does work, I wonder if trying to get gutenprint added to fink 
> might not be the path forward.  Not quite as convenient but at least 
> it'll be there.

It would be great if someone would step forward here for macos build(s).  I can produce a package, but it would be unsigned and not notarized by Apple.  I don't know how that would work on other's machines, and I'm not sure we would want such a layman's package on the site.

The third party package managers for macos are fink, mac ports, and brew.  One of them might be interested.  I have used all three of them at one point or another.  My biggest objection to outside package managers is all the prerequisites they pile on to get their stuff to work.  

> 
> BTW, I highly recommend 'make check-parallel' instead.  :D

I just started it running.

Matt

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

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

On Tue, Aug 06, 2024 at 03:59:38PM -0500, Matt Broughton wrote:
> At the least, the fix can be memorialized on the list.  The fix for 
> macos is to do away with a custom option for printing on CD/DVDs.

The discussion was too long ago to jog my memory, but I'm not in favor 
of killing this option for everyone because MacOS is um, differently abled. 

> When we found this fix, it was felt that the custom option was important to keep wherever possible.  Using something like 
> #ifdef __APPLE__ 
> was not favored, but nothing was ever resolved.  If genppd.c could be 
> modified and a conditional #ifdef __APPLE__ addition, or something 
> else) is palatable, it would be appreciated.  I'm not a coder, so I 
> can't give the exact code needed.

Given a choice between "Completely broken on MacOS but works for 
everyone else" and "disable this feature for MacOS and leave it enabled 
for everyone else" I'm much in favor of the latter.

I do worry about the support requests, but I suppose this is the lest 
crappy choice.

> The v5.3.5-pre1 release does build nicely from the command line on 
> machines of both architectures (macos 12.5 x86_64 and macos 14.5 
> arm64).  The `make check` was took about 8 hours, but everything 
> passed.

It builds, but does it... well, work with actual printers?  (And I'm 
especially curious about the dyesub backend; integrating that required a 
lot of headaches in the past)

If it does work, I wonder if trying to get gutenprint added to fink 
might not be the path forward.  Not quite as convenient but at least 
it'll be there.

BTW, I highly recommend 'make check-parallel' instead.  :D

 - 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] RFC: New release and abandoning MacOS?

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

> On Jun 29, 2023, at 9:27 AM, Matt Broughton <wal...@ma...> wrote:
> 
>> 
>> On Jun 28, 2023, at 8:19 PM, Solomon Peachy <pi...@sh... <mailto:pi...@sh...>> wrote:
>> 
>> On Wed, Jun 28, 2023 at 07:44:55PM -0500, Matt Broughton wrote:
>>> I am not sure I know all of the macOS issues or how difficult it would 
>>> be to accomodate them.  I do know that the v5.3.x macOS releases are a 
>>> show stopper for printers that can print on CDs or DVDs. No Printer 
>>> Features can be seen in the GUI.  Even trying to see the Printer 
>>> Features will crash some applications. PPDs can be modified to resolve 
>>> this issue.  Alternatively, genppd.c can be modified.  I have a 
>>> modified genppd.c we used for testing that fixes the issue.
>> 
>> Since this is due to a PPD construct, I assume this problem happens with 
>> remote network printers (set up to use a PPD instead of IPP) as well as 
>> locally-attached ones?
> 
> I believe that is correct.
> 
>> 
>> Meanwhile, what's the technical argument against merging this change?
> 
> It isn't a technical argument.  It is a feature issue.  The problem under macOS is using custom CD sizes.  That is where the user can manually enter a value in the print window that isn't contained in the spin box.  The PPD needs to have the following lines removed--
> 
> *CustomStpCDOuterDiameter True: "pop"
> *ParamCustomStpCDOuterDiameter Value/Value: 1 points 184 340
>  
> *CustomStpCDInnerDiameter True: "pop"
> *ParamCustomStpCDInnerDiameter Value/Value: 1 points 45 121
>  
> *CustomStpCDXAdjustment True: "pop"
> *ParamCustomStpCDXAdjustment Value/Value: 1 points -30 30
>  
> *CustomStpCDYAdjustment True: "pop"
> *ParamCustomStpCDYAdjustment Value/Value: 1 points -30 30
> 
> Implementing the change globally takes away an important feature for non-macOS users.  There was no decision on how to deal with this.  It didn't seem palatable to test for Apple platform in the source code.
> 
> Matt

I'm going to bring this up again in light of v5.3.5-pre1 being released.  Would there be any interest in making a change in genppd.c to alleviate a macos bug?  I know macos is officially deprecated, but there will always be those that compile it for themselves.  It would be helpful to have the fix in the repository.

At the least, the fix can be memorialized on the list.  The fix for macos is to do away with a custom option for printing on CD/DVDs.

diff --git a/Users/matt/GutenGit/gimp-print-source/src/cups/genppd.c b/Users/matt/Downloads/genppd.c
index 194cf42..0c7e2ce 100644
--- a/Users/matt/GutenGit/gimp-print-source/src/cups/genppd.c
+++ b/Users/matt/Downloads/genppd.c
@@ -987,6 +987,7 @@ print_one_option(gpFile fp, stp_vars_t *v, const stp_string_list_t *po,
       print_close_ui = 0;
       gpprintf(fp, "*CloseUI: *Stp%s\n\n", desc->name);
 
+#if 0
       /*
        * Add custom option code and value parameter...
        */
@@ -995,7 +996,7 @@ print_one_option(gpFile fp, stp_vars_t *v, const stp_string_list_t *po,
       gpprintf(fp, "*ParamCustomStp%s Value/%s: 1 points %d %d\n\n",
               desc->name, _("Value"), (int) desc->bounds.dimension.lower,
               (int) desc->bounds.dimension.upper);
-
+#endif
       break;
     case STP_PARAMETER_TYPE_INT:
       gpprintf(fp, "*OPOptionHints Stp%s: \"input spinbox\"\n", lparam->name);

When we found this fix, it was felt that the custom option was important to keep wherever possible.  Using something like 
#ifdef __APPLE__ 
was not favored, but nothing was ever resolved.  If genppd.c could be modified and a conditional #ifdef __APPLE__ addition, or something else) is palatable, it would be appreciated.  I'm not a coder, so I can't give the exact code needed.

The v5.3.5-pre1 release does build nicely from the command line on machines of both architectures (macos 12.5 x86_64 and macos 14.5 arm64).  The `make check` was took about 8 hours, but everything passed.

Matt

Re: [Gimp-print-devel] [External] EcoTank ET-2810

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

On 5/8/24 15:14, Matsumura, George wrote:
> Greetings,
> 
> I was able to use the Epson Expression ET-2750 EcoTank driver for an Epson
> ET-2800 EcoTank and it seemed to work well enough. I hope it may do so for you
> as well.

Thankyou George.M,

I couldn't find ET-xxxx names in the list but just found 'Expression 
ET-xxxx' names that i can look at.
-- 
regards,
Russell

Re: [Gimp-print-devel] [External] EcoTank ET-2810

[Matsumura, G. <gm9...@oh...>]

Greetings,

I was able to use the Epson Expression ET-2750 EcoTank driver for an Epson
ET-2800 EcoTank and it seemed to work well enough. I hope it may do so for you
as well.

Regards,
    George

On 8/4/24 22:52, Russell Shaw wrote:
> Use caution with links and attachments.
> 
> Hi,
> 
> I was looking at adding the ET-2810 in
> gimp-print-source/src/xml/printers/escp2.xml but got a bit overwhelmed
> by the model variations in /gimp-print-source/src/xml/escp2/model/
> 
> It uses dye ink.
> 
> <https://www.epson.com.au/products/ecotank/ET-2810_Specs.asp>
> 
> I read print-escp2.h and print-escp2.c, but it would take a while before
> i figure out anything (i read the manual, but it'll still take a while)
> 
> What's the quickest way to get something working that i can look at
> later? I could try random other printers but there's a lot.
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

[Gimp-print-devel] EcoTank ET-2810

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

Hi,

I was looking at adding the ET-2810 in 
gimp-print-source/src/xml/printers/escp2.xml but got a bit overwhelmed 
by the model variations in /gimp-print-source/src/xml/escp2/model/

It uses dye ink.

<https://www.epson.com.au/products/ecotank/ET-2810_Specs.asp>

I read print-escp2.h and print-escp2.c, but it would take a while before 
i figure out anything (i read the manual, but it'll still take a while)

What's the quickest way to get something working that i can look at 
later? I could try random other printers but there's a lot.

Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD

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

On Sat, Aug 03, 2024 at 10:46:07AM -0400, Michael Sweet wrote:
> There is support for this in PAPPL (in order to minimize inter-job 
> delays) so that bodes well for a future Gutenprint printer application 
> at least... :)

Absolutely.  There are a _lot_ of goodies that are either badly 
shoehorned through the existing CUPS frontend, or simply waiting for the 
day when I can finally bring them into the light.

> So for higher-level formats (PDF in particular) that isn't a problem.  
> For raster printing you'd be forced to transform the color data on the 
> back side - not ideal/optimal but doable.

This is another area where having some sort of predefined "profile" 
would be handy. 

A while back I picked up a couple a of surplus ID card printers with an 
eye towards disrupting this (even more proprietary and vendor lockd-in) 
space as well. I had some initial success but the sheer cost of these 
printers (and no meaningful interest/feedback) kept me from pursuing 
this space any further.

***
After I (mostly) broke the propretary SDK-based stranglehold that held 
back these bigger dyesub printers from wider usage. Heck, to this day 
the only reason most (if not all) of this space has _any_ IPP support at 
all is because it came for free on top CUPS+Gutenprint)

> So for the printers I've written drivers for in the past, the overcoat 
> option has always been on/off (boolean) with the ribbon determining 
> the type (glossy/matte/etc.)

That was true in the earlier days of this space, but pretty much 
everything under two decades old supports Glossy or Matte selection with 
the same ribbon.

Meanwhile, CX-02 that spawned this thread supports four different 
overcoat types -- None, Glossy, Matte, and Fine Matte. 

As an added bonus it also supports a so-called "partial [fine] matte" 
mode where the user can supply an image that acts as a glossy/matte 
mask, allowing for the creation of a psuedo-watermark effect.  (From the 
printer's perspective, you send this partial/mask over as a second 
set of image data...)

> 1. Define new finishing enums/keywords for this.
> 2. Default it based on print quality (best/high == decurl, draft/normal == no-decurl)

....It needs to be generally independent of "quality".  (Or at least 
this is one area where the user's definition of "quality" may disagree 
with the printer's definition.)

> I know there is a strong temptation to put this in drivers, but really 
> these are things best left to the Client software to supply you with a 
> good image and for the driver/printer to reproduce the image as 
> accurately/consistently as possible.

You're preaching to the choir here, but this is another area where 
things get a little messy, for two reasons:

1) Vendors typically have differentiated themselves with (eg) "the 
Fujifilm look" and this way no matter which of their models was used to 
print an image, or how (ie native SDK, OS/driver(itself written using 
said SDK), whatever), you'll get consistent-looking output and 
not-so-coincidentally locked in to their ecosytem.  Especially when 
_not_ using a formal color managed flow, which is the norm for 
consumer/prosumer spaces.

2) While these printers typically accept 8bpp YMC or RGB raster data, 
translating that over to individual heating elements on the thermal 
print head is a complex process where any given pixel influences the 
others around it in dedicedly non-linear manners.  Most of these 
printers implement these algorithms in realtime using a dedicated ASIC 
or FPGA, but others require this to be pre-computed by the "driver".  
These algorithms usually include a mandatory sharpening pass and other 
knobs that tie into (1).

The worst offender here is (well, was) Mitsubishi. All but two of the 
models they released since 2007 work this way.  Sinfonia requires 
something similar on both of their current 6" models (albeit with no 
user-facing knobs). HiTi is a convoluted mess, with mulitple "color 
modes" with corresponding printer data tables _and_ ICC profiles.

> There are rare cases where post processing on the printer/driver side 
> is desirable (I do this in LPrint to improve bar code legibility for 
> example, and color management is another common one) but the guiding 
> principle should be to do only what is necessary to reproduce what 
> you've been given accurately.

This is basically (2) above, but yes, I am otherwise in complete 
agreement.  (FWIW, color management is one of those things that nobody 
ever seems to get right..)

> Yes, the device communication layer is a significant bunch of code, 
> and it might indeed need to be forked to port it to PAPPL.  I hope 
> not, though...

A while back I did some significant internal restructuring to make it a 
little more easily adaptable, but there's definitely going to be some 
headaches when the time comes.

> Not exactly, it is just that when you are used to using the hammer 
> yourself it is sometimes hard to think about telling the printer to do 
> something that might use a hammer or might use a different tool to 
> accomplish the same goal.  With IPP you specify print intent, not the 
> low-level detailed instructions.

Well, yeah -- from the _client_ side it's pretty sweet, but from the 
printer/server side, it's the difference between a writing an 
application and having to build/maintain a bespoke container/virtual 
machine -- A huge increase in scope.

> This has been the case for other printers as well.  And even in the 
> IPP era there are custom client applications for managing these 
> printers and their jobs.  That won't change...

...But they have to be implemented in a fundamentally different manner.

> So from a (sorry) short-sighted perspective IPP provides no benefit.  

...Welcome to... the sad reality of most corporate decision making?

> But when you look at costs over decades (and believe me there are 
> people that do just that) having a standard protocol for talking to 
> your fleet of devices has HUGE benefits.  

Sure.  Except the folks with the fleets aren't the folks manufacuring 
the printers, and thre are some very pererse incentives in play.

As an example of how insanely myopic these folks can be -- I have been 
engaged by the US or EU branches of printer manufacturers to effectively 
reverse engineer or deubug issues with their own printers, as their 
corporate parents steadfastedly refused to even supply documentation 
*internally* to meet high-profile customer needs. (Usually a variation 
of "we need a solution that can run on a cheap Arm SBC instead of an 
expensive Windows PC")

A project manager at one of these manufacturers later told me that I had 
very nearly been sued -- and he'd only prevented that by making it it 
very loudly known out that this very same company was about to launch a 
new product built on top of what I'd written (ie dysub backend).  This 
turned into a productive (but rocky) multi-year engagement that finally 
ended when their legal team actually did threaten me, this time over a 
feature that had saved them something like half a million dollars.

So... Yeah.  "Short sighted" doesn't begin to describe it.

That final legal nastygram was four years ago, was also the last 
interaction I've had with any printer manufacturer or medium/large scale 
priting solution provider.  And honestly, good riddance.

However. While the manufacturers (and these solution providers) don't 
care, end-users (including myself) that just want to print their photos 
certainly do care.  After all, I only ever started in this space because 
the manufacturers weren't meeting my needs.  And that, along with my 
unhealthy obsession in low-level tinkering, tinker with low-level stuff, 
is why I'm still doing this.

> Initial time to print *might* be impacted slightly but once you start 
> pushing jobs IPP and network interfaces are faster than the print 
> engine(s).

...If there are sufficient resources to buffer multiple jobs.  
Hilariously the printers are nearly always capable of that, but the 
driver stacks on top... not so much.

> Being able to monitor what is happening in a heterogeneous environment 
> helps to keep things running smoothly and avoids dependance on a 
> single vendor/supply chain.

To end-users, that's a huge benefit.  To middleware folks... it _could_ 
be.  To printer makers, making it easy to switch to a competitor 
is empatically a *bad* thing.

> The core IPP protocol is unchanged from the version published by the 
> IETF in 1998.

By "IPP" I mean "IPP Everywhere" aka "driverless printing".  That didn't 
land until what, 2010, and took another decade to become truly 
widespread?

> Um, IPP *is* inherently superior to port 9100 and LPD.  Not only do 
> you get encryption and authentication support, you also get status 
> information, job management, etc. that are all MISSING from port 9100 
> and LPD (as implemented by printers).  "Print and pray" is how port 
> 9100 and LPD are viewed...

I'm not comparing IPP to LPD here; if you don't have a network 
interface, _neither_ is an option.

...but you're once again talking about general purpose *end user* 
benefit, not benefit to the manufacturers themselves.  Or even to their 
primary volume customers, who already have their own 
vertically-integrated printing solutions (eg drugstore photo printing 
kioks) that for all I know are already built around IPP.

And from that perspective, the dyesub makers' attitude of "our volume 
customers don't care (and if anything, want us to be _cheaper_) and for 
the little one-off guys that do, just sell a cheesy little add-on print 
server that provides those services" has been GoodEnough(tm) so far.

...If they want or need more than that, they've certainly never 
communicated that with me, much less expressed any interest in helping 
to make it happen.  Suffice it to say, I'm not holding my breath.

 - 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] Citizen CX-02 incorrect paper dimensions in PPD

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

Solomon,

> On Aug 2, 2024, at 1:12 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Thu, Aug 01, 2024 at 12:36:01PM -0400, Michael Sweet wrote:
>> Actually, if it was a "cut media" option that is fairly well supported 
>> these days and maps well to IPP...
> 
> Except... contemporary clients at the time didn't present the option.

Linux at least... macOS has had "CutMedia" (that's the PPD option) support a long time to support roll-fed printers but I know it took a while to get that into the various Linux print dialogs.

>> Third option: offer a 2x6 page size and merge pages in a job to the 4x6 media.
> 
> I've actually tried to go down variations of this path multiple times, 
> but kept running into the fundamental problem that 98% of the time for 
> photo printing, each image/page is submitted as an independent job. (ie 
> unless you create a multi-page PDF and submit that) Which, the last time 
> I checked, neither iOS or Android's printing functionality (&| their 
> photo apps' use of said functionality) work that way.

Multiple document job support is optional in IPP so from iOS you'll either see a single PDF/raster job with multiple pages (one image per page) *or* multiple jobs with a single image per page, depending on whether the printer supports the image file format.  For current iOS clients the original format is typically HEIF and since that format is a patent minefield I'm not aware of any printers that actually support it.  (Certainly CUPS and PAPPL have no plans of supporting it in the near future)

> So there's no way to do job combining (for the typical users) without 
> creating some sort of daemon that sits around and waits after one job is 
> "finished" for something else to show up before asynchronously sendng 
> something to the printer.

There is support for this in PAPPL (in order to minimize inter-job delays) so that bodes well for a future Gutenprint printer application at least... :)

> ...
> Meanwhile, there's another wrinkle for things like ID cards printers, 
> where each side of the card may require completely different parameters 
> to the point of full CMYK on the front but only K the back (and K can be 
> greyscale or 1bpp resin. oh, and different per side.  It all depends on 
> the ribbon being used.  Which also may or may not have a lamination 
> layer on either side)..  I don't know if that level ove 
> each-page-has-different-properties is even expressible under IPP.

So for higher-level formats (PDF in particular) that isn't a problem.  For raster printing you'd be forced to transform the color data on the back side - not ideal/optimal but doable.

We don't currently have a separate attribute for specifying back side resolution/type information, and while that *could* be added I'm guessing it wouldn't be likely to be implemented by IPP clients for the same reasons other low-probability scenarios don't get implemented... :/  But still, for those clients that *do* want to support it we can define them, something like:

- "pwg-raster-document-back-type-supported (1setOf type2 keyword)": Supported color spaces and bit depths for the back side of pages in a PWG raster document.
- "pwg-raster-document-back-resolution-supported (1setOf resolution)": Supported resolutions for the back side of pages in a PWG raster document.

> ...
> Just off the top of my head: Printer resolution, paper size

printer-resolution
media/media-col

> and the 
> number/position of cuts (which are nearly always a fixed set of 
> enumerated combinations as opposed to being a finishing option on 
> any/all print sizes)

finishings/finishings-col (which handles the different number and position of cuts)

> common finishing options (eg overcoat type

So for the printers I've written drivers for in the past, the overcoat option has always been on/off (boolean) with the ribbon determining the type (glossy/matte/etc.)

IPP exposes overcoat as a finishing option, and can even specify a type of coating.  Most clients will simply offer a checkbox (coating/no-coating).

> and 
> decurling),

So I've seen printer-implemented "drying" timers to minimize curling/wrinkling/transfer off the printed media, but not an optional finishing step to (I assume) roll out the media to straighten it.  There are two ways we could approach this:

1. Define new finishing enums/keywords for this.
2. Default it based on print quality (best/high == decurl, draft/normal == no-decurl)

I actually think a combination of the two might be ideal, i.e., if #1 isn't specified then do #2, but this is definitely a finishing step that should be selectable.

> sharpening and color correction knobs,

I know there is a strong temptation to put this in drivers, but really these are things best left to the Client software to supply you with a good image and for the driver/printer to reproduce the image as accurately/consistently as possible.

There are rare cases where post processing on the printer/driver side is desirable (I do this in LPrint to improve bar code legibility for example, and color management is another common one) but the guiding principle should be to do only what is necessary to reproduce what you've been given accurately.

> delay time for 
> automatic job combining,

This is probably best as a configuration option in the printer application.  Letting an ordinary user control this from a job could lead to problems.

> quality/speed settings, etc.

print-quality and print-speed are both available.

> Incidently, For whatever reason, scaling, etc *still don't* seamlessly 
> work, based on the complaints I still get about white margins showing up 
> on the sides of prints.

Scaling has long been an issue, even before CUPS.  Part of this is technical, but part is how different users look at scaling (visual-spatial thinkers vs. verbal-sequential) which is why it is so important to have a preview image in the print dialog... :)

> ...
>> and *that* combined with a lack of incentive to support products 
>> beyond their release is the reason for broken drivers, NOT changes 
>> made by Apple.
> 
> Not *solely*, perhaps.  But when those same printer manufacturers 
> release drivers for newer versions of Windows, but not MacOS.. as the 
> saying goes, where there's smoke, there's probably fire.

macOS represents a very small marketshare to them, and quite frankly you can't get away with as much bad programming on macOS as on Windows...

Moreover, Apple has had AirPrint since 2010 which allows manufacturers to support a single thing on their printers for both macOS (small share) and iOS (big share), and Apple has actively pushed them to support AirPrint over writing more drivers during the same period.  And of course once you have done AirPrint it is trivial to support Mopria (Android/ChromeOS/Windows) and IPP Everywhere which are based on the same technology.

> ...
>> But I *do* want to have a discussion to understand the issues 
>> surrounding supporting certain printers so that a) I can advocate for 
>> those kinds of printers in the Printer Working Group, b) I can make 
>> sure that PAPPL supports what is needed for those printers, and c) I 
>> can eventually help make Gutenprint available as a printer 
>> application.
> 
> I'll tackle these in reverse order.
> 
> (c) PAPPL makes a hell of a difference, of course, and for minimal 
> "Print office documents on USB-print-class-compliant PCL/inkjet 
> printers" it should't be _that_ much effort. (Basically everything but 
> the dyesubs) This is the scope of the recurring GSoC efforts.  Assuming 
> that succeeds this third time, here are two major followup prongs:
> 
> * Figure out how to make available the approximately one gajillion 
>   knobs for tuning the printer output (especially for Epson inkjets) 
>   You've already said they can't be directly exported due to IPP client 
>   limitations, so maybe this can be done using some sort of 
>   configurable profile mechanism.  Which has to be created, along with 
>   suitable UI, etc etc.
> 
> * Figure out how to adapt/integrate the gutenprint USB dyesub backend's 
>   functionality in a way that doesn't result in a hard fork and 
>   wholesale duplication of code. Aside from basic communications, this 
>   includes job combining and splitting, various processing functions 
>   that couldn't be done within gutenprint (due to layering or licensing 
>   considerations), media/status reporting, configuring nonvolatile 
>   printer options, and even firmware updates for one printer family.

Yes, the device communication layer is a significant bunch of code, and it might indeed need to be forked to port it to PAPPL.  I hope not, though...

> ...
> (Which reminds me -- I _still don't have an answer on what we should be 
> doing with respect to the original complaint that led to this thread; 
> ie "the printer accurately reports that it uses custom sizes, and 
> lying/pretending otherwise will require fundamental alterations to how 
> it works with sizes internally, plus rescaling/padding/cropping what 
> the user supplied.")

I'll think on this - now that I at least know *why* you are doing this I might be able to come up with an alternative that will work.

> (b) I touched on sone of this above, but ultimately the only way we're 
> going to know what else PAPPL needs is to (heh) FAFO.  This is what I 
> was referring to with my "lead bullets" remarks -- it's going to take a 
> lot of work, and I'd hoped the GSoC stuff would start that rolling.
> 
> (a) When I was first introduced to Java, and someone described it as 
> "making hard things easy and easy things hard."  That seems to apply to 
> IPP as well.

Not exactly, it is just that when you are used to using the hammer yourself it is sometimes hard to think about telling the printer to do something that might use a hammer or might use a different tool to accomplish the same goal.  With IPP you specify print intent, not the low-level detailed instructions.

> FWIW, I don't speak for anyone other than myself (based in part on 
> conversations and general industry exposure over the years)
> 
> First, these aren't "printers" so much as "industrial equipment", 
> deployed as part of some larger system that produces something that is 
> will be sold for money.

Keep in mind that IPP is also widely used in "light production" environments for printing books (old school), posters, newsletters, magazines, signs, etc. that are all sold for money.

> As such, this class of printers is only rarely "shared" over a network.  
> Printing is nearly exclusively using direct connections from a custom 
> application running on the local system. More often than not, the 
> OS-level printer stack is bypassed competely.

This has been the case for other printers as well.  And even in the IPP era there are custom client applications for managing these printers and their jobs.  That won't change...

> From that perspective, IPP is completely superfluous.  Both because the 
> functionality it offers is unnecessary (least of which being that all 
> printing is local) and because even in a best-case scenario, it adds a 
> _lot_ of overhead that just slows things down.  (In this general market, 
> time-to-print and prints-per-hour (with each print typically being a 
> separate self-contained job!) numbers can matter even more than the 
> incremental price-per-print)

So from a (sorry) short-sighted perspective IPP provides no benefit.  But when you look at costs over decades (and believe me there are people that do just that) having a standard protocol for talking to your fleet of devices has HUGE benefits.  Initial time to print *might* be impacted slightly but once you start pushing jobs IPP and network interfaces are faster than the print engine(s).

Being able to monitor what is happening in a heterogeneous environment helps to keep things running smoothly and avoids dependance on a single vendor/supply chain.

> For situations when these printers need to be made available to generic 
> applications, they provide standard OS drivers.  And if the printer 
> needs to be exported over the network, the OS can handle that.  Why 
> reimpement the wheel and drive product complexity & cost upwards when it 
> won't be of use to the majority of the suer base?

Some operating systems don't support printer drivers...

> Meanwhile, these are printers that have production lifecycles that 
> routinely exceed a decade, and are supported well beyond that.  IPP has 
> iterated so rapidly (and the reality of having a network-facing device) 
> is such that it makes sense for an industrial printer maker to 
> completely decouple this functionality.

The core IPP protocol is unchanged from the version published by the IETF in 1998.

We have added new attributes, values, and operations at a DECREASING rate over the last 26 years, and always in a way that preserved backwards compatibility.

The initial IPP printers basically treated IPP as another raw protocol (port 9100, LPD, and IPP), but since 2010 IPP has been a first-class protocol with support for standard file formats.

> ...
> So while they care about IPP, it is not because of any inherent 
> superiority of IPP, but because that's what it takes to support 
> AirPrint.

Um, IPP *is* inherently superior to port 9100 and LPD.  Not only do you get encryption and authentication support, you also get status information, job management, etc. that are all MISSING from port 9100 and LPD (as implemented by printers).  "Print and pray" is how port 9100 and LPD are viewed...

________________________
Michael Sweet

[Gimp-print-devel] Borrarme

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

Borrarme de este correo

Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD

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

On Thu, Aug 01, 2024 at 12:36:01PM -0400, Michael Sweet wrote:
> Actually, if it was a "cut media" option that is fairly well supported 
> these days and maps well to IPP...

Except... contemporary clients at the time didn't present the option.

> Third option: offer a 2x6 page size and merge pages in a job to the 4x6 media.

I've actually tried to go down variations of this path multiple times, 
but kept running into the fundamental problem that 98% of the time for 
photo printing, each image/page is submitted as an independent job. (ie 
unless you create a multi-page PDF and submit that) Which, the last time 
I checked, neither iOS or Android's printing functionality (&| their 
photo apps' use of said functionality) work that way.

So there's no way to do job combining (for the typical users) without 
creating some sort of daemon that sits around and waits after one job is 
"finished" for something else to show up before asynchronously sendng 
something to the printer.

Incidently, that's one of the things I was most excited about a Printer 
Application; intra-job state effectively comes along for free. There's 
actually a _lot_ of automagic page/job combining logic sitting unused in 
the backend right now.  Suffice it to say I'd _really_ like to have this 
capability...

Meanwhile, there's another wrinkle for things like ID cards printers, 
where each side of the card may require completely different parameters 
to the point of full CMYK on the front but only K the back (and K can be 
greyscale or 1bpp resin. oh, and different per side.  It all depends on 
the ribbon being used.  Which also may or may not have a lamination 
layer on either side)..  I don't know if that level ove 
each-page-has-different-properties is even expressible under IPP.

> That's not CUPS, that is GNOME, KDE, etc.

And more importantly, iOS, Android...

(Actually, Gnome, KDE, etc worked just fine.  Pretty sure they still do, 
 if you use local CUPS queues instead of the auto-discovered IPP stuff)

> Which functionality exists for these printers beyond the size of the 
> output and the number of copies? (orientation, scaling, etc. are all 
> handled by the client)

Just off the top of my head: Printer resolution, paper size and the 
number/position of cuts (which are nearly always a fixed set of 
enumerated combinations as opposed to being a finishing option on 
any/all print sizes) common finishing options (eg overcoat type and 
decurling), sharpening and color correction knobs, delay time for 
automatic job combining, quality/speed settings, etc.

Incidently, For whatever reason, scaling, etc *still don't* seamlessly 
work, based on the complaints I still get about white margins showing up 
on the sides of prints.  (that's slowly improved thanks to Till's work 
with cups-filters, but telling non-technically-inclined people they have 
to effectively recompile their environment's entire printing stack (or 
"use a different application to print your pictures") doesn't go over 
well...)

> It isn't reasonable to assume that a driver written for MacOS X 10.2 
> on PowerPC and *never* updated would continue to work on macOS 14 on 
> Intel/ARM some 22 years later, even if the printer it supports still 
> works.  

Oh I agree, except I'm not talking about a gap like that.  Instead it's 
tier-ones like Canon not providing drivers for anything more than a 
single MacOS release, outright refusing even to consider relase+1.

Incidently, I have one printer in my fleet that was introduced in *2003* 
and is _still_ actively supported (new media, firmware, and current 
Windows drivers) by its manufacturer.  But that's an outlier; typically 
these things have a product lifecycle a bit over a decade.

> But don't try to blame Apple for printer vendors failing to support 
> their products

I'm sorry, but Apple absolutely carries at least part of the blame here, 
and I say that as someeone who has been involved with trying to provide 
MacOS printer drivers.  Nearly *every* MacOS release for the better part 
of a decade broke something Gutenprint depended on, becoming a release 
blocker.  (That's why Gutenprint hasn't generated a new formal release 
since *2019*.  It would be one thing if we derived actual *revenue* from 
MacOS and used that to pay folks to do this work, but that's not how 
this works)

> printer vendors have historically used terrible software engineering 
> practices (no version control/code repositories, no way to re-build 
> their software, etc.) 

I'm all too familiar with this, unfortunately.

> and *that* combined with a lack of incentive to support products 
> beyond their release is the reason for broken drivers, NOT changes 
> made by Apple.

Not *solely*, perhaps.  But when those same printer manufacturers 
release drivers for newer versions of Windows, but not MacOS.. as the 
saying goes, where there's smoke, there's probably fire.

And when you consider these printers require use of 
printer/model-specific media (ie ribbon+paper) and that's where the real 
money lies.  The easier it is for folks to make prints, the more they 
will print, the more media you will sell, and the more money you make.  

Of course, that doesn't mean the printer manufacturer won't shooot 
themselves in the foot. To beat up on Canon again, their latest SELPHY 
CP printers use the same media kits as the first model they ever 
produced over two decades ago.  There have been only two hardware 
generations (each with its own PDL and communication) in that whole 
time, yet for some reason they insist on each individual model requiring 
a unique driver... which they almost never update or support after the 
initial release.

> The biggest "breakage" events were when PPC emulation was removed 
> (10.6) and when code signing became required (10.14).

That 10.6 period largely coresponds with my increasing involvedment with 
Gutenprint, and 10.13 or 10.14 was when our support effectively ended.

> I'm not at Apple anymore but they don't seem to be changing anything 
> meaningful in the printing stack on macOS...

FWIW it usually wasn't the "printing stack" that broke us, but something 
_else_ in the OS.

> One of my goals has been to support/develop/mentor a Gutenprint 
> printer application based on PAPPL. That would give you your 
> command-line RIP *and* instant support for all of the IPP-based 
> clients.

Till and I are on our third consecutive GSoC attempt to make this 
happen. But there's a wide gap between "willing to help/support/mentor" 
and "doing it myself."  But more on that in a bit.

> *I* am *not* trying to put this all on your shoulders, and I also 
> totally understand that supporting Gutenprint (or any printing 
> software) is a mostly thankless task... 

To put it mildly.

As you can probably tell from these emails, I only ever had an interest 
in the low-level printer interaction sort of stuff. Other than reworking 
my talk-to-the-printer code to be usable as a CUPS backend, Everything 
else higher in the well-layered stack (largely including the rest of 
Gutenprint) was SomeoneElse'sProblem(tm).  And that worked fine for a 
long time, becuse there were OtherPeople maintaining those parts of the 
overall system.

Except those OtherPeople have all left or otherwise abandoned the rest 
of the stack -- heck, the entire printing _system_ -- I simply don't 
have the personal bandwidth to tackle everything. Or much of anything.

To quote Ben Horowitz [1]:

  "There are no silver bullets for this, only lead bullets."  

Every path forward requires competent developers to (a) carefully write 
a decent pile of very domain-specific code, and (b) support/maintain it 
going forward.

And unless someone wants to throw a pile of money my way [2], that 
person wont't be me.

..And while (a) might represent 90% of the overall effort, (b) 
represents the second 90%.  (as demonstrated by the initial context of 
this email)

> But I *do* want to have a discussion to understand the issues 
> surrounding supporting certain printers so that a) I can advocate for 
> those kinds of printers in the Printer Working Group, b) I can make 
> sure that PAPPL supports what is needed for those printers, and c) I 
> can eventually help make Gutenprint available as a printer 
> application.

I'll tackle these in reverse order.

(c) PAPPL makes a hell of a difference, of course, and for minimal 
"Print office documents on USB-print-class-compliant PCL/inkjet 
printers" it should't be _that_ much effort. (Basically everything but 
the dyesubs) This is the scope of the recurring GSoC efforts.  Assuming 
that succeeds this third time, here are two major followup prongs:

 * Figure out how to make available the approximately one gajillion 
   knobs for tuning the printer output (especially for Epson inkjets) 
   You've already said they can't be directly exported due to IPP client 
   limitations, so maybe this can be done using some sort of 
   configurable profile mechanism.  Which has to be created, along with 
   suitable UI, etc etc.

 * Figure out how to adapt/integrate the gutenprint USB dyesub backend's 
   functionality in a way that doesn't result in a hard fork and 
   wholesale duplication of code. Aside from basic communications, this 
   includes job combining and splitting, various processing functions 
   that couldn't be done within gutenprint (due to layering or licensing 
   considerations), media/status reporting, configuring nonvolatile 
   printer options, and even firmware updates for one printer family.

Anything beyond the minimal GSoC scope is almost guaranteed to require 
creating new libgutenprint (and libgutenprintui) APIs, likely 
significant frontend work within PAPPL's UI, plus heavy modifications of 
the dyesub code within core gutenprint and its external (>33KLoC!) 
backend (which in turn also likely requires mucking with PAPPL)

...All this before anything _new_ is added beyond the current feature set.

(Which reminds me -- I _still don't have an answer on what we should be 
 doing with respect to the original complaint that led to this thread; 
 ie "the printer accurately reports that it uses custom sizes, and 
 lying/pretending otherwise will require fundamental alterations to how 
 it works with sizes internally, plus rescaling/padding/cropping what 
 the user supplied.")

(b) I touched on sone of this above, but ultimately the only way we're 
going to know what else PAPPL needs is to (heh) FAFO.  This is what I 
was referring to with my "lead bullets" remarks -- it's going to take a 
lot of work, and I'd hoped the GSoC stuff would start that rolling.

(a) When I was first introduced to Java, and someone described it as 
"making hard things easy and easy things hard."  That seems to apply to 
IPP as well.  

FWIW, I don't speak for anyone other than myself (based in part on 
conversations and general industry exposure over the years)

First, these aren't "printers" so much as "industrial equipment", 
deployed as part of some larger system that produces something that is 
will be sold for money.

As such, this class of printers is only rarely "shared" over a network.  
Printing is nearly exclusively using direct connections from a custom 
application running on the local system. More often than not, the 
OS-level printer stack is bypassed competely.

From that perspective, IPP is completely superfluous.  Both because the 
functionality it offers is unnecessary (least of which being that all 
printing is local) and because even in a best-case scenario, it adds a 
_lot_ of overhead that just slows things down.  (In this general market, 
time-to-print and prints-per-hour (with each print typically being a 
separate self-contained job!) numbers can matter even more than the 
incremental price-per-print)

For situations when these printers need to be made available to generic 
applications, they provide standard OS drivers.  And if the printer 
needs to be exported over the network, the OS can handle that.  Why 
reimpement the wheel and drive product complexity & cost upwards when it 
won't be of use to the majority of the suer base?

Meanwhile, these are printers that have production lifecycles that 
routinely exceed a decade, and are supported well beyond that.  IPP has 
iterated so rapidly (and the reality of having a network-facing device) 
is such that it makes sense for an industrial printer maker to 
completely decouple this functionality.

Now the makers know that there are other markets for these printers, and 
those markets may require driver-less network printing support. This was 
traditionally handled using a "hot folder" sort of arrangement (ie you 
upload files to a network share) running on some sort of server (these 
days typically Linux+SAMBA) which prints them out based on 
pre-configured settings) but more recently, AirPrint etc has allowed 
them to support mobile-centric clients (usually thanks to CUPS).

So while they care about IPP, it is not because of any inherent 
superiority of IPP, but because that's what it takes to support 
AirPrint.  Even with AirPrint+IPP, everyone seems to heavily push their 
own dedicated apps that give the user a richer experience (more control 
knobs, better status reporting, and I'm sure all sorts of data 
collection and tie-ins with various cloudy services).  I have no idea if 
these apps also use IPP under the hood (I know Canon's doesn't!), but 
years ago I was told that the first version the app to one 
manufacturer's print server was motivated by standard iOS printing not 
supporting/exposing some critical feature. (In hindsight it was probably 
the ability to configure the printer to generate 2x6" strips instead of 
a single 4x6")

ANYWay. To loop back to the beginning, IPP lets folks do all sorts of 
complicated things relatively easily, but it makes "simple" things a lot 
harder because the simple things have to be handled the same way as the 
complicated things. So when all you care about are those "simple" things 
(because you already have elaborate business-specific 
software/infrastructure to take care of the complicated stuff) it 
becomes an easy "all cost, but no benefit" decision to make.

Where they do care about IPP in of itself, it is because they are 
selling additional products (or services) that build on top of the 
actual printers.  The stuff on top iterates rapidly (one maker I'm 
familar with has gone through at least four major hardware revisions and 
even more software revisions of their "print server" sice 2015) but the 
actual printers do not.  (their _newest_ model was releasd in 2020 and 
the oldest still-in-production model was introduced in 2011, only 
because they had to cease prouction of a model introduced in 2007 due to 
COVID supply chain issues, and it remains in active support to this day)

 [1] https://a16z.com/lead-bullets/
 [2] ie enough for me to quit my never-had-anything-to-do-with-printing
     $dayjob.  Which I am _really_ happy at, btw.

 - 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] HP Designjet510 Mac

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

> On Aug 2, 2024, at 4:48 AM, in...@ju... wrote:
> 
> Hi there,
>  
> I wonder if you have a driver available for HP DesignJet 510 CH336 for Mac OS 14?

Unfortunately, The DesignJet is not supported by the Gutenprint drivers.

Matt

[Gimp-print-devel] HP Designjet510 Mac

[<in...@ju...>]

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
	{font-family:Helvetica;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Aptos;
	panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
	{font-family:"Avenir Next Condensed";
	panose-1:2 11 5 6 2 2 2 2 2 4;}
@font-face
	{font-family:"Avenir Next Condensed Demi Bold";
	panose-1:2 11 7 6 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:11.0pt;
	font-family:"Aptos",sans-serif;
	mso-ligatures:standardcontextual;
	mso-fareast-language:EN-US;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Aptos",sans-serif;
	color:windowtext;}
MsoChpDefault
	{mso-style-type:export-only;
	font-size:11.0pt;
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style></head><body lang=EN-GB link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi there,<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>I wonder if you have a driver available for HP DesignJet 510 CH336 for Mac OS 14?<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Many thanks,<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>Leon<o:p></o:p></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal><a href="http://www.juicegraphics.co.uk/"><span style='color:windowtext;text-decoration:none'><img border=0 width=616 height=231 style='width:6.4166in;height:2.4062in' id="Picture_x0020_4" src="cid:image001.png@01DAE4C9.7F82D110" alt="signature_285000956"></span></a><span style='mso-ligatures:none'><o:p></o:p></span></p></div><p class=MsoNormal><span style='mso-ligatures:none'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><b><span style='font-size:18.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:#FF40FF;mso-ligatures:none;mso-fareast-language:EN-GB'>OPENING TIMES</span></b><b><span style='font-size:9.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><br></span></b><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'>Monday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;9.00am to 5.00pm<br>Tuesday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9.00am to 5.00pm<br>Wednesday: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 9.00am to 12.00pm<br>Thursday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9.00am to 5.00pm<br>Friday:&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 9.00am to 5.00pm<br>Saturday:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; 9.00am to 12.00pm<br><br>Please note: <o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'>We are closed Bank&nbsp;Holiday Weekends which includes the Saturday.<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'>There may be times where we will need to close 15mins earlier so that we can take deliveries.<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-fareast-language:EN-GB'><img border=0 width=607 height=102 style='width:6.3229in;height:1.0625in' id="Picture_x0020_3" src="cid:image002.png@01DAE4C9.7F82D110" alt="signature_1374648201"><span style='mso-ligatures:none'><o:p></o:p></span></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:16.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:#3B7D23;mso-ligatures:none;mso-fareast-language:EN-GB'>Please consider leaving us a review on our Trustpilot site…<o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><a href="https://uk.trustpilot.com/review/juicegraphics.co.uk"><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-fareast-language:EN-GB;text-decoration:none'><img border=0 width=605 height=148 style='width:6.302in;height:1.5416in' id="Picture_x0020_2" src="cid:image003.png@01DAE4C9.7F82D110" alt="signature_3977238747"></span></b></a><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p></o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><b><span style='font-size:10.5pt;font-family:Helvetica;color:black;mso-ligatures:none;mso-fareast-language:EN-GB'><o:p>&nbsp;</o:p></span></b></p><p class=MsoNormal><span style='mso-ligatures:none'><img border=0 width=618 height=7 style='width:6.4375in;height:.0729in' id="Picture_x0020_1" src="cid:image004.png@01DAE4C9.7F82D110" alt="signature_1839912480"><o:p></o:p></span></p><p class=MsoNormal><span style='mso-ligatures:none'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><b><span style='font-size:9.0pt;font-family:"Avenir Next Condensed Demi Bold",sans-serif;color:black;mso-ligatures:none'>Please consider the environment when&nbsp;printing this email.</span></b><span style='font-size:9.0pt;font-family:"Avenir Next Condensed",sans-serif;color:black;mso-ligatures:none'><br>&nbsp;<br>This email (including any attachments) is&nbsp;meant only for the intended recipient.<br>It may also contain confidential and&nbsp;privileged information.<br>If you are not the intended recipient, any&nbsp;reliance on, use, disclosure, distribution&nbsp;or copying of this email or attachments is&nbsp;prohibited.&nbsp;<br>Please notify the sender immediately by&nbsp;email if you have received this message&nbsp;by mistake and delete the email and all&nbsp;attachments.&nbsp;<br>Any views or opinions in this email are&nbsp;solely those of the author and do not&nbsp;necessarily represent those of Juice&nbsp;Graphics UK. Juice Graphics UK accepts&nbsp;no liability for the content of this email, or&nbsp;for the consequences of any actions&nbsp;taken on the basis of&nbsp;the information&nbsp;provided, unless that information is&nbsp;subsequently confirmed in writing.<br><br>Although every reasonable effort is made&nbsp;to keep its network free from viruses,&nbsp;Juice Graphics UK accepts no liability for&nbsp;any virus transmitted by this email or any&nbsp;attachments and the recipient should use&nbsp;up-to-date virus checking software.<br><br>Email to or from this address may be&nbsp;subject to interception or monitoring for&nbsp;operational reasons or for lawful&nbsp;business practices.</span><o:p></o:p></p></div></body></html>

Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD

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

Solomon,

> On Aug 1, 2024, at 10:37 AM, Solomon Peachy <pi...@sh...> wrote:
> ...
> This userbase (notably including myself) don't care about application 
> print dialogs or cross-OS support; they have an image generated by some 
> pre-existing pipleine, and they want it to programmically come out a 
> given printer (which may or may not be directly attached) with a given 
> set of near-arbitrary options.
> 
> This is the _only_ use case I've ever cared about.

That's where *I* started with the Gimp-Print plugin all those years ago...

> ...
>> Except.. this entire discussion is about how Gutenprint _isn't_ using 
>> standard sizes, and why can't it just do that instead?
> 
> More backstory here -- Let's take the CX-02 again.  The overwhelmingly 
> common use cases for this class of printers are drugstore-type photo 
> kiosks and photobooths, producing "standard" 4x6inch and a pair of 2x6" 
> strips respectively.
> 
> From the printer's perspective, both are *completely* identical.. except 
> the latter has one extra cut applied.  How do we present this option to 
> the user?  There were two approaches:
> 
> * Single PageSize (eg 4x6inch) with an additional, nonstandard/custom 
>   "cut in half" option that (a) many UIs don't display or support, (b) 
>   only works with some sizes, (c) no usable way to present feedback to 
>   the user about what combinations are valid.  (fun fact: I actually 
>   implemented code that emitted PPD UIConstraints, and you told me to 
>   not bother because what few clients implemented it were hopelessly 
>   broken)

Actually, if it was a "cut media" option that is fairly well supported these days and maps well to IPP...

>    - OR -
> 
> * Do what every printer maker's official Windows (and MacOS) drivers do 
>   and present them as two distinct PageSizes (eg 4x6inch and 2x6*2) for 
>   the user to choose between.

Third option: offer a 2x6 page size and merge pages in a job to the 4x6 media.

> Naturally, I did the latter, and it worked just fine... until AirPrint.  

The changes you speak of happened for CUPS 1.4, which was released in 2009 (16 years ago...)

> Or more accurately, CUPS moving to an IPP-first model, which combined to:
> 
> * "helpfully" deduplicate "media" with the same physical dimensions 
>    even if it had different identifiers.
> * Not presenting _any_ options other than the basic "size, color, 
>   orientation, duplexing, copies" needed for typical office printing 
>   tasks.

That's not CUPS, that is GNOME, KDE, etc.

> ...
> If there's a better way to do this, I'd love to hear it. But any 
> approach has to work with existing deployed print clients *today*.
> 
> Again, any "solution" that doesn't support required functionality is an 
> complete non-starter -- Printing Is Revenue. It Has To Work, Now.

Which functionality exists for these printers beyond the size of the output and the number of copies?

(orientation, scaling, etc. are all handled by the client)

> ...
> Ironically, it's not the commercial dyesub printing niche that generates 
> the support burden.  Instead, that has historically come from MacOS 
> users whose consumer-grade printers were abandoned by their makers 
> (helped along by Apple's near-constant breaking things printer drivers 
> relied upon).

It isn't reasonable to assume that a driver written for MacOS X 10.2 on PowerPC and *never* updated would continue to work on macOS 14 on Intel/ARM some 22 years later, even if the printer it supports still works.  Obviously if you still have the same hardware/OS, it will continue to work.  But don't try to blame Apple for printer vendors failing to support their products - printer vendors have historically used terrible software engineering practices (no version control/code repositories, no way to re-build their software, etc.) and *that* combined with a lack of incentive to support products beyond their release is the reason for broken drivers, NOT changes made by Apple.

During my tenure at Apple we bent over backwards to preserve driver compatibility. Sometimes that meant shipping old shared libraries that drivers were using (but shouldn't have been), or including code translation support (PPC to Intel, Intel to ARM), or leaving holes in the sandbox/security profiles for specific drivers until they could be updated.  The biggest "breakage" events were when PPC emulation was removed (10.6) and when code signing became required (10.14).  I'm not at Apple anymore but they don't seem to be changing anything meaningful in the printing stack on macOS...

> ...
> In the end, it looks like I will go back to where this started for me; 
> ie a command-line-based RIP for direct-attached dye-sublimation 
> printers, and I'll release under a copyleft license in the hope that 
> other folks find it useful.

One of my goals has been to support/develop/mentor a Gutenprint printer application based on PAPPL. That would give you your command-line RIP *and* instant support for all of the IPP-based clients.

*I* am *not* trying to put this all on your shoulders, and I also totally understand that supporting Gutenprint (or any printing software) is a mostly thankless task...  But I *do* want to have a discussion to understand the issues surrounding supporting certain printers so that a) I can advocate for those kinds of printers in the Printer Working Group, b) I can make sure that PAPPL supports what is needed for those printers, and c) I can eventually help make Gutenprint available as a printer application.

________________________
Michael Sweet

Re: [Gimp-print-devel] Citizen CX-02 incorrect paper dimensions in PPD

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

On Wed, Jul 31, 2024 at 08:01:45PM -0400, Solomon Peachy via Gimp-print-devel wrote:
> (I understand that some, maybe even most use cases don't care about 
>  this, but improvements to _other_ use cases don't matter if the ones 
>  you do care about cease to work!)

I've been trying to understand just why this silly and mostly pointless 
email exchange has aggivated me so much.

The short version is that I never actually _cared_ about general 
purporse printing.  My personal use cases consist nearly entirely of 
command-line RIP-type stuff.  Along those lines, the only 
current/classic CUPS functionality I care about is a generic mechanism 
to enumerate and specify options.

I got into this space when I ended up with a printer that didn't do what 
it said on the box (ie "print images from memory cards").  The 
officially supported vendor drivers (under MacOS and Windows) were utter 
crap, a trait also shared by what appeared to be pretty much everything 
in the market.  Heck, this is _still_ largely the case.

So I decided to do something about this so I could use this printer 
natively under Linux, in the vein of Top Gear's "How hard can it really 
be?" quip.  Armed with Gutenprint's support for older models in the 
family, I rolled up my sleeves and figured out that (1) the printer used 
a different command language than its older siblings, (2) Gutenprint 
makes it pretty easy to add new printers into, and (3) this printer 
didnt't follow USB Printer class specs so the existing CUPS UPS backend 
didn't work.

Two days after I started, I had something that worked well enough for my 
immediate need -- printing arbitrary images from Gutenprint's GIMP 
plugin.

Since then I basically become the "dye sublimation printer guy". Over 
the years what I wrote grew into the all-singing CUPS backend it is 
today, supporting something like 150 distinct models from pretty much 
every manufacturer.  Between the backend and Gutenprint, *every* printer 
feature is supported, and thanks to how CUPS exposes options, you didn't 
have to resort to proprietary per-manufacturer (and often per-printer) 
SDKs to get exactly what you wanted: Consistent looking prints no matter 
which printer you were using.

This userbase (notably including myself) don't care about application 
print dialogs or cross-OS support; they have an image generated by some 
pre-existing pipleine, and they want it to programmically come out a 
given printer (which may or may not be directly attached) with a given 
set of near-arbitrary options.

This is the _only_ use case I've ever cared about.

But thanks to CUPS, my work was automagically applicable to other use 
cases -- Indeed, most of the time, Gutenprint+CUPS worked _better_ than 
the manufacturer's official drivers (and/or SDKs) for $other_os.

> Except.. this entire discussion is about how Gutenprint _isn't_ using 
> standard sizes, and why can't it just do that instead?

More backstory here -- Let's take the CX-02 again.  The overwhelmingly 
common use cases for this class of printers are drugstore-type photo 
kiosks and photobooths, producing "standard" 4x6inch and a pair of 2x6" 
strips respectively.

From the printer's perspective, both are *completely* identical.. except 
the latter has one extra cut applied.  How do we present this option to 
the user?  There were two approaches:

 * Single PageSize (eg 4x6inch) with an additional, nonstandard/custom 
   "cut in half" option that (a) many UIs don't display or support, (b) 
   only works with some sizes, (c) no usable way to present feedback to 
   the user about what combinations are valid.  (fun fact: I actually 
   implemented code that emitted PPD UIConstraints, and you told me to 
   not bother because what few clients implemented it were hopelessly 
   broken)

    - OR -
 
 * Do what every printer maker's official Windows (and MacOS) drivers do 
   and present them as two distinct PageSizes (eg 4x6inch and 2x6*2) for 
   the user to choose between.

Naturally, I did the latter, and it worked just fine... until AirPrint.  
Or more accurately, CUPS moving to an IPP-first model, which combined to:

 * "helpfully" deduplicate "media" with the same physical dimensions 
    even if it had different identifiers.
 * Not presenting _any_ options other than the basic "size, color, 
   orientation, duplexing, copies" needed for typical office printing 
   tasks.

In other words, it became effectively _impossible_ to simultaneously 
support the two overwhelmingly predominant use cases for dyesub 
printers.  A common workaround was to create multiple printer queues, 
each limited to a single print size.  This approach scales very poorly 
due to exponential numbers of option combinations.

After being pestered about this for some time, I came up with a hack -- 
Each same-physical-size-but-different-cuts variations got bumped up by 
one point.  Native CUPS/PPD didn't care, AirPrint+CUPS was happy, and 
being full bleed printers anyway, Gutenprint could just drop the extra/ 
superfluous data.

If there's a better way to do this, I'd love to hear it. But any 
approach has to work with existing deployed print clients *today*.

Again, any "solution" that doesn't support required functionality is an 
complete non-starter -- Printing Is Revenue. It Has To Work, Now.

> That sounds like a significant functional regression in the UIs.

I don't know when this happened, but what's one more UI/UX setback at 
this point?

> Meanwhile.  Let's suppose that everything you have said is 100% 
> objectively true -- ie that Gutenprint's approach is fundamentally 
> incompatible with TheWayThingsAreNowDone(tm), and large parts of it have 
> to be rewritten and its overall scope greatly expanded... or what 
> exactly?

...For the record I actually agree.  But that agreement doesn't 
magically make time and resources magically appear.

> Because this really sounds like I'm being "asked" to volunteer myself 
> for a solid 2-3 months of unpaid full time work to produce something 
> that OtherPeople(tm) want.  Then actively maintain, update, and support 
> it indefinitely.  For free.
> 
> ...Screw that.

This is the crux of the matter.  Above, I wrote about why I got into 
this printing space to begin with, and what my personal use cases 
(still) are.  All of this IPP (and for the most part, even CUPS) stuff 
is at best tangental, yet it is responsible for nearly all of my headaches.

Ironically, it's not the commercial dyesub printing niche that generates 
the support burden.  Instead, that has historically come from MacOS 
users whose consumer-grade printers were abandoned by their makers 
(helped along by Apple's near-constant breaking things printer drivers 
relied upon).

Then it was heavily supplemented by iPhone/Airprint users. And Android 
users. and now, Windows users.  All of these are on the long tail ends 
of _very_ complex (and nearly entirely proprietary) software stacks that 
I have nearly zero influence over or visibility into.  Bug reports are 
little better than "printing doesn't work properly".  Indeed, the only 
piece I have _any_ visibility into or meaningful control over is 
Gutenprint, a thin sliver crushed at very bottom of that heap.

I got into this printing space to get away from dealing with those 
complicated (and proprietary) stacks that only served to get in the way of 
what I wanted to do.  If anything, it seems like the new status quo is 
actually _worse_.

There are of course significant advantages/benefits for a native IPP 
frontend to Gutneprint (combined with a great deal of internal 
restructuring and new development to take advantage of the new 
possibilities).  But those benefits nearly entirely accrue to *other 
people*.  Meanwhile, the *costs* of making all of that happen fall 
nearly entirely on... me, if only beacause I didn't have the good sense 
to formally walk away sooner.

Not only that, but as best as I can tell, for my use cases, the end 
result is actually functionally _worse_ thanks to the harsh reality of 
crappy IPP clients and the increase in overall system and runtime 
complexity.  

In the end, it looks like I will go back to where this started for me; 
ie a command-line-based RIP for direct-attached dye-sublimation 
printers, and I'll release under a copyleft license in the hope that 
other folks find it useful. 

Heck, that's effectively what I've been doing all along anyway.

> Gutenprint is 100% Free Software (GPLv2+), provided AS-IS and WITHOUT 
> ANY WARRANTY WHATSOEVER.  And as the sayings go, "scratch your own 
> itches" and "patches welcome".

Faced with high costs and negligible (if not outright negative) personal 
benefits, how can the rational conclusion be anything other than "Let 
the people who want this functionality do the siginficant work to make 
it happen."

(To your immense credit, IPP Everywhere is... everywhere! Seriously, 
 that's an amazing accomplishment.)

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