Re: [Gimp-print-devel] Canon Pro-100

[Ken S. <ke...@sm...>]

Hi Robert,

Thanks for your kind words. I've attached a copy of the json file which 
builds the Gutenprint plugin for flatpak Gimp. Note that the cups driver 
is built directly from the github repository version, while Gutenprint 
is built from the latest version checked out from my local repository 
(it can also be built from a local directory). Both are standard builds, 
and Gutenprint runs as a Gimp plugin, loaded automatically, just as it 
does when running native. If anyone needs more complete information 
about building/running, let me know. [BTW, my background is low-level, 
process control, C/C++, and I had to learn json to do this, one of the 
reasons it took me a day or two and is still a little rudimentary.]

I can probably run the regression suite - I'm running an Inspiron 13 
with i7 and 16GB. Biggest problem with little machines like this is its 
cooling is marginal, and when running a long compute-intensive process 
it gets pretty hot. So I may just run with one or two cores.

I just got an email from Gernot, so I'll write him next.

Ken

On 12/21/20 5:51 PM, Robert Krawitz wrote:
> On 12/21/20 7:29 PM, Ken Smolek wrote:
>> 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.
> Good stuff!
>
> Do you mean libgutenprint, the Print plugin, or Gutenprint+CUPS?  I don't have any experience with
> Flatpak, but if it's like other container technologies, it needs all of the resources built into the
> image except for specific external interfaces (it would defeat the purpose to give it host
> filesystem access).  I also don't know how (or if) layering works with flatpaks; can you use the
> GIMP flatpak as a base and then layer the other stuff (the CUPS libraries in particular) in it.
>
> I known Sambhav Dusad was working on a printing application, which would eliminate the need for the
> Gutenprint plugin altogether by subsuming its functionality.  Sambhav, have you made any progess on
> this?  Is there anything more we can do to help you?
>
>> 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.
> Gernot Hassenpflug is our Canon maintainer, and you'll want to discuss it with him.  But this sounds
> great.
>
>> 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.
> We do have a pretty thorough regression suite (invoked via make check-parallel); depending upon how
> fast your machine is it could take quite a while to run, since it runs a lot of cases.  You can also
> run just the testpattern tests on the Canon driver by
>
> cd src/testpattern
> ./run-testpattern-2 -f canon -s
>
> which will be a lot faster.  If you have multiple cores, you can run
>
> STP_PARALLEL=<n> ./run-testpattern-2 ...
>
> to use n cores.
>
>> [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.]
> I guess one day we should migrate to Github or Gitlab, where we could take pull requests without
> having to go through all of this rigamarole.
>
>> 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?
> Lots of printing of test patterns, I'm afraid...
>
>> 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.
> We should be able to roll this into the existing canon driver.  Gernot, could you take a look at this?
>
>> 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.
> The real goal is to have a printing application
> (https://openprinting.github.io/upcoming-technologies/01-printer-application/), then the PPD files
> go away altogether and we have a much more flexible interface.
>
>> 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.
> No apology at all needed -- this is great stuff and we're really glad to hear from you!
>
>> Keep up the very good work, and have a good holiday season.