Canon Pro-100

Hi Gutenprint developers,

I want to say how impressed I am with your commitment over all these 
years, and with
the work you've done for all of us.

I want to apologize in advance for the length of this. And I also want 
to apologize for any comments I make which might be construed as 
disparaging - they're not intended in that way. As a long-time software 
developer, I understand the tradeoffs that come with any software, and 
that software has to be written for what is, not what might be in the 
future. I also realize that I still have a limited understanding of much 
of the code, so my opinions may be entirely incorrect.

I started printing again after a long hiatus, using my old but still 
very functional Epson
2200. I'm running Centos 7.8 (another story of obsolescence) But I 
wanted to run the latest Gimp (2.10.22), and Centos 7 supports 2.8.22. I 
discovered that flatpak offers
a runtime for Gimp 2.10.22, but there was no Gutenprint available. It 
took quite a bit of time, but I built a flatpak version of 
Gutenprint-5.3.3. It's not as clean as I would like, because the Gimp 
runtime environment does not include CUPS, so I have to build and 
install that as well (it's all done as part of a single JSON file). In 
addition, the Gimp environment has to be modified with overrides: PATH 
has to be modified to find the CUPS and Gutenprint files, and 
STP_DATA_PATH has to be added to give access to the XML files. It's 
functional, and I can print via USB or LPD (using an RPi as the print 
server); I haven't gotten IPP to work, but it's low on my priority list. 
In any case, the flatpak version works.

Then I came across a pristine Canon Pro-100 for almost nothing and 
bought it, which has turned out to be a monumental rabbit hole. But I'm 
retired and have nothing better to do, especially in a pandemic, so I 
tackled it.

With no Gutenprint/CUPS driver, and little or no documentation (that 
mostly from Gutenprint and Ghostscript, nothing from Canon), it's been a 
very tedious process of reverse engineering of the command strings. And 
the Canon printer driver [print-canon.c:canon_setup_channels()] takes an 
approach to subchannels which doesn't work for the Pro-100, which, as 
near as I can tell, demands that channels be output in the order 
CMYcmkHL. In addition, the raster output string [formerly ESC(nn nn F 
data] has been expanded to take a 4-byte length, and is now ESC(N nn nn 
nn nn F data.

To make a very long, 2-month story short, I have a working Canon Pro-100 
under Gutenprint which uses all 8 inks and prints photos which are not 
perfect, but are of pretty high quality. Images converted to grayscale 
in Gimp print very well, but I have been unable to get straight 
monochrome printing (using an inkset consisting of black, gray, and 
light gray - kHL) to work.

I've tried very hard not to break existing code, but obviously there are 
no guarantees of that. Where I added significant code to handle the 
Pro-100, I generally did it by creating new functions, which are called 
only if the printer is PIXMA Pro100. In some cases, I simply added the 
Pro-100 to an already-existing set of printers in a long if statement. 
Code was added as necessary for inks, modes, media, etc. The mask 
protocol in print-canon.h is still a little mysterious to me, but I'm 
reluctant to mess with it more than necessary.

[BTW, I started from a downloaded 5.3.3 tar file. I set up a local git 
repository with my changes in a Pro100 branch, so all modifications from 
the canonical version are visible.]

Print quality improved dramatically when I included the standard Canon 
hue, sat and luminosity curves to the Pro-100 printer definition - that 
was when I realized I might have a really usable driver. But it's still 
not perfect - I've done some tweaking in the Adjust Output screen, but 
I'd love to be able to improve the curves and LUTs. Is there a 
description anywhere of how the hue/sat/lum arrays are generated?

So, where do I go from here? This is very close to a driver I can use 
for my own prints, but it's not production software. And I have no way 
of regression testing to see what I may have broken. If you prefer, it 
can just stay here as a local modification for my personal use. Or we 
could attempt to integrate it in some way, possibly by creating a 
print-canon-pro.c which is completely separate from the existing 
print-canon.c. This would have been a reasonable way to go initially, 
but hindsight is 20-20, and I didn't
really understand what I was getting myself into.

Another possibility is to implement an IPP driver for the printer and 
try to eliminate the Pro100 ppd entirely. That's an attractive 
possibility to me, but I'm still vague on the actual process, and I'll 
have to take another look at the IPP sample code to see just how 
complicated it will be. Your opinions are welcome.

Apologies again for the length of this, and if somebody's already 
implemented a working Pro-100 I don't know about, at least I learned a lot.

Keep up the very good work, and have a good holiday season.

Ken Smolek