gimp-print-devel

Re: [Gimp-print-devel] Request support for "Kyocera FS-1020MFP"

[gene h. <ghe...@sh...>]

On 9/2/24 08:31, Amin Guermazi wrote:
> Dear Gutenprint team,
> Your project is very useful. However, I'm afraid my printer's model 
> isn't supported yet.
> 
> Its name is "Kyocera FS-1020MFP"
> 
> I'd be pleased if you can fulfill my request. Thanks in advance.
> 
I cannot find a linux driver for that model # on the kyocera site, I'd 
take it back. Brother has drivers and they work for every feature the 
box brags about. You might query the openprinting list.
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

Re: [Gimp-print-devel] [SPAM] Request support for "Kyocera FS-1020MFP"

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

On Sun, Sep 01, 2024 at 10:38:07PM +0100, Amin Guermazi wrote:
> Its name is "Kyocera FS-1020MFP"

According to Kyocera, this printer only supports a "host-based" PDL 
instead of something standardized (eg PCL or Postscript)
 
> I'd be pleased if you can fulfill my request. Thanks in advance.

In order for Gutenprint to add support for this model, we need to know 
how the printer expects the page data to be generated and sent over. 
This information can be obtained in one of two ways:

 (a) comprehensive technical documentation from Kyocera, or
 (b) a significant, time-consuming reverse-engineering effort by 
     someone with direct physical access to one of these models.

Once there is sufficient documentation as to how this printer works, 
only then can an actual driver be written.  This also represents a 
non-trivial amount of effort.

It will be far, far cheaper to just replace the printer with one that uses
a standard PDL.

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

[Gimp-print-devel] Request support for "Kyocera FS-1020MFP"

[Amin G. <min...@gm...>]

Dear Gutenprint team,
Your project is very useful. However, I'm afraid my printer's model isn't
supported yet.

Its name is "Kyocera FS-1020MFP"

I'd be pleased if you can fulfill my request. Thanks in advance.

Re: [Gimp-print-devel] Help

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

The LPrint software (https://www.msweet.org/lprint) provides a TSPL driver that *should* work with this printer, which is based on the same direct thermal print engine as dozens/hundreds of other printers of that type.

> On Aug 18, 2024, at 6:55 AM, Adım Kırtasiye <adi...@ho...> wrote:
> 
> Hello. I bought a Gprinter 3100 tu thermal barcode device, but I could not install it on my Mac device. Do you have a macos driver for this device? This is my job, it's very critical and that's why I don't want to go back to Windows. I would be very happy if you could help me.
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 

________________________
Michael Sweet

[Gimp-print-devel] Help

[Adım K. <adi...@ho...>]

Hello. I bought a Gprinter 3100 tu thermal barcode device, but I could 
not install it on my Mac device. Do you have a macos driver for this 
device? This is my job, it's very critical and that's why I don't want 
to go back to Windows. I would be very happy if you could help me.

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

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

> On Aug 10, 2024, at 9:31 AM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> 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.

You can also edit the libusb-1.0.pc.in file before you build.  Add @LIBS@ to the end of the line for Libs: so it reads:
Libs: -L${libdir} -lusb-1.0 @LIBS@

Matt

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