After a lot of searching over months I found the answer to my question.
You have to change on a Mac system settings the country settings to USA to get Imperial measurements.
Would have been much easier if the measurements option had been included in the software.
Just in case someone else needs to do it.
Russ.

Yes, I am sending half of the job to one printer, and then as soon as it finishes spooling, I’m sending the second half to the other printer. So, as a test, if I send the first half to the second printer, and the second half to the first printer, the first printer should inherit the slowing issue. I will test that theory. Thanks, Mike.

What do you mean by "split"?  Are you just printing to one printer and then immediately printing to the other and then they print simultaneously after the jobs are sent to both?

It's possible that your Windows spooler just runs slower because Qimage is sending more data.  Qimage generally sends more data to the printer than Photoshop since it interpolates to the printer's native PPI while Photoshop just dumps the original image to the driver.

Regards,
Mike

I am needing to split a print job between two Epson 1430 printers. For this project, speed is a factor, so I have AI Co-Pilot disabled. The settings for both printers are the same, with "high speed" checked. If I split the job in QImage, one printer is nearly three times faster than the other. If I split the job in PhotoShop, both print at roughly the same speed. What am I doing wrong?

This explains my bad experience with LZW. I had only ever archived 16bit TIFFs.
Thank you
Ernst

The issue with doing it that way is that LZW and ZIP compression don't work on 16 bit files.  If the images are edited already, there is little to be gained in saving copies as 16 bits/channel.  Take a look at the sizes below for a detailed image with lots of foliage (hard to compress):

16 bit TIFF:
None: 142 MB
LZW:  144 MB

8 bit TIFF:
None: 71 MB
LZW:  30 MB

Mike

To tell you the truth: No, I haven't :-(
I haven't used LZW for a long time because it delays saving and often produces larger files than the uncompressed image file.
But your idea is a good one and that is why I have now carried out further investigations. I have tested different file formats using two different photos.
The first photo contains a lot of detail, which makes efficient compression more difficult.
The second photo shows a blue sky with a few clouds, which should be very easy to compress.

Here are the results:

Grainy wall with detailed wooden door    size [KB]               size [%]
                        (6176x8858px)
TIFF 16bit uncompressed                       320615                    100,00
TIFF 16bit LZW                                      416507                 129,91
TIFF 16bit ZIP                                       315873                    98,52
PNG 16bit fast                                       270140                    84,26
PNG 16bit medium                                 270135                    84,26
PNG 16bit small                                     269503                    84,06
JXL 16bit lossless                                   208481                    65,03   <<<
JXL 16bit quality 100                                24279                     7,57
JXL 8bit transcode from JPEG                    31055                     9,69
JPEG 8bit                                                37303                    11,63


Cloudy sky (9504x6336px)
TIFF 16bit uncompressed                         352901               100,00
TIFF 16bit LZW                                        399351               113,16
TIFF 16bit ZIP                                         325475                 92,23
PNG 16bit fast                                         249114                70,59
PNG 16bit medium                                   242573                68,74
PNG 16bit small                                       242539                68,73
JXL 16bit lossless                                     177324                50,25   <<<
JXL 16bit quality 100                                   3903                  1,11
JXL 8bit transcode from JPEG                       8347                  2,37
JPEG 8bit                                                  10269                 2,91

For both images, the LZW TIFF file saved with Photoshop was larger than the uncompressed TIFF file.
I got the same result when saving with Affinity Photo.
"JXL 8bit transcode from JPEG” means the following: JXL allows a lossless conversion from JPEG to JXL. That means, that the already lossy information of the JPEG will not lose more details by converting it to JPEG XL. But the resulting file is only slightly smaller than the JPEG file.
“JXL 16bit quality 100” is the storage method I tested with Affinity Photo.
Although this is not lossless, I could not detect any visual differences to the original - not even when overlaying in Photoshops layers using “Difference” at 100% view.
This extreme compression rate is still somewhat suspect to me and I would not yet trust it completely. But even the lossless compression is significantly better than with all other file formats. And as I have already checked, color profiles are also supported.
Best regards,
Ernst

Have you compared JXL with lossless compression vs TIFF with lossless compression (say LZW compression)?

Mike

I fully understand your concerns.
I am currently only aware of a few programs that support JXL file format. One of them is Affinity Photo. Affinity Photo can both open and save JXL image files. Unfortunately, Photoshop can only open them using Adobe Camera Raw but not save them. Color profiles are supported - this was one of my first tests before I converted my biggest TIFF space hogs to JXL. As far as the file format itself is concerned, I can see no disadvantage compared to JPEG or TIFF. The big advantage is, that JXL compresses much better than JPEG and also saves 16bit images. Compared to a TIFF file, the size of a lossless!! compressed JXL file is less than 1/5 of the TIFF size.
Unfortunately, it seems to me that this format is being pushed aside as much as possible by influential “big players” although it has better features than png, webp, avif, heic, ... It would be high time that TIFF was finally replaced by a more modern file format with better properties.
Nevertheless, thank you very much for your quick reply. Either way, I don't want to do without Qimage any more.
Best regards,
Ernst

Right now the format is too obscure to be of any use in Qimage.  There is too little support for the format and in the few samples I was able to find, there is no sign of an ICC profile in the image.  Without an embedded profile, the image is useless.

So I guess we will have to wait and see if the format gains any traction and there is a more definitive spec and third party support.

Regards,
Mike