gimp-print-devel

[Gimp-print-devel] Photo Print Quality issue Canon G2000 series

[Jonathan I. <drc...@gm...>]

Hi, I am using the gutenprint v 5.3.3-4 on Ubuntu 20.04-1 and I notice that
when printing photos (I am using 4x6 glossy, photo mode) and pictures have
a low bitrate look to them... almost pixelated. I have set DPI to max
600x600 and nothing seems to help. Not sure if this is a potential bug?

packages:

gimp-*guten*print/focal 5.3.3-4 amd64

*guten*print-doc/focal 5.3.3-4 all

*guten*print-locales/focal 5.3.3-4 all

lib*guten*print-common/focal,now 5.3.3-4 all [installed,automatic]

lib*guten*print-dev/focal 5.3.3-4 amd64

lib*guten*print-doc/focal 5.3.3-4 all

lib*guten*print9/focal,now 5.3.3-4 amd64 [installed,automatic]

lib*guten*printui2-2/focal 5.3.3-4 amd64

lib*guten*printui2-dev/focal 5.3.3-4 amd64

printer-driver-*guten*print/focal,now 5.3.3-4 amd64 [installed]

Cheers!

Re: [Gimp-print-devel] Canon PIXMA MP130 driver

[Protea W. J. <aik...@gm...>]

On Tue, Dec 29, 2020 at 1:48 AM Jean-Michel Lépine via Gimp-print-devel <
gim...@li...> wrote:

> Hello,
>
> I am interested with a Canon PIXMA MP130 driver (all in one
> printer/scanner) for Ubuntu 20.04.1 LTS.
>
> I tried without success the "Canon PIXMA iP1500 - CUPS+Gutenprint
> (OpenPrinting LSB 3.2) v5.2.7 Simplified and en" and obtained the error
> message :  "Printer configuration error. There is a missing print filter
> for 'Canon_MP130'". :-(
>
> Please, could you help me ?


Hello Jean-Michel,
I am afraid you are out of luck. Neither the MP130 or the iP1500 (and
several other models) are supported.
They use a data format which has not been reverse-engineered yet. I guess
you are using a very old version of gutenprint in which some experimental
code was tried temporarily.
Best regards,
Genot Hassenpflug

>
>

[Gimp-print-devel] Canon PIXMA MP130 driver

[Jean-Michel L. <jm....@la...>]

Hello,

I am interested with a Canon PIXMA MP130 driver (all in one 
printer/scanner) for Ubuntu 20.04.1 LTS.

I tried without success the "Canon PIXMA iP1500 - CUPS+Gutenprint 
(OpenPrinting LSB 3.2) v5.2.7 Simplified and en" and obtained the error 
message :  "Printer configuration error. There is a missing print filter 
for 'Canon_MP130'". :-(

Please, could you help me ?

Best regards,

-- 
Jean-Michel LÉPINE
Bordeaux, France

Re: [Gimp-print-devel] Canon Pixma MG 8150 with OS X 10.14 Mojave

[Protea W. J. <aik...@gm...>]

On Mon, Dec 28, 2020 at 12:49 AM esc...@bl... <esc...@bl...>
wrote:

> Hello,
>
> Canon stopped good working printers with "Fehler B200" called "printer
> death". Some month ago I could revitalize it. But now, all seems lost.
> After MG 5350 I could buy an old MG 8150 to use my ink storage.
> But Canon does not support OS X 10.14 and the old driver didn't work at
> all. After three days of searching I found Guteprint and was very very
> lucky! So I hadn't to throw away a good working printer. Thank you!!!
>
> Now my question:
>
> 1. I can't activate the back paper tray
>
> 2. when I use "Label print" for CDs it uses the back paper tray.
>
> Is there any solution in sight for this problems?
>

Hello,
Thanks for the report.
The MG8100 series seems to have an error in the paper tray definition then.
I will look into that.
1. IIRC the use of trays in some of the recent models is a bit tricky,
depending on media type and size, so to help me perhaps you can tell me
whether you are using plain media or something more exotic.
2. The CD tray issue is probably the same thing, an incorrect definition.
3. Please note that CD printing is not working properly, any print will
likely not be centered, but I would love to get some help debugging this if
you are up for it.

Best regards,
Gernot Hassenpflug

[Gimp-print-devel] Canon Pixma MG 8150 with OS X 10.14 Mojave

[<esc...@bl...>]

Hello,

Canon stopped good working printers with "Fehler B200" called "printer death". Some month ago I could revitalize it. But now, all seems lost. After MG 5350 I could buy an old MG 8150 to use my ink storage. 
But Canon does not support OS X 10.14 and the old driver didn't work at all. After three days of searching I found Guteprint and was very very lucky! So I hadn't to throw away a good working printer. Thank you!!!

Now my question:

1. I can't activate the back paper tray

2. when I use "Label print" for CDs it uses the back paper tray.

Is there any solution in sight for this problems?

Thank you an kind regards

Henry Guanter

Re: [Gimp-print-devel] HP laserjet 1020 printer driver

[Robert K. <rl...@al...>]

On 12/23/20 11:06 AM, Marc Sbar wrote:
> Hi,
> 
> I have a HP LaserJet 1020 and recently installed big sur on my iMac.   The old printer driver did
> not work and I could not find one on the hp site.   I do note that you show a driver for the HP
> laserjet 1022, which I think worked on past systems.   Will this work for the 1020 or do you have a
> driver that is directly applicable for my printer?

Hi,

Despite the similarities between the printers, the 1020 does not support the standard printing
laguage for laser printers (PCL), and we don't have a way to support it.  There may be another
driver that does; I'm just not aware of it.

[Gimp-print-devel] HP laserjet 1020 printer driver

[Marc S. <mar...@co...>]

Hi,

I have a HP LaserJet 1020 and recently installed big sur on my iMac.   The old printer driver did not work and I could not find one on the hp site.   I do note that you show a driver for the HP laserjet 1022, which I think worked on past systems.   Will this work for the 1020 or do you have a driver that is directly applicable for my printer?

Thanks,
Marc Sbar


Marc Sbar
mar...@co...
mar...@gm...
home: (520) 760-0992
cell: (281) 804-8912

Re: [Gimp-print-devel] Driver for Samsung CLX-series

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

> On Dec 21, 2020, at 7:56 AM, Anton Spieker <ant...@ho...> wrote:
> 
> 
> Hello,
> 
> I’ve been searching very long for a driver, that works with the Samsung CLX-3185.
> I would be very happy, if you could integrate this printer.
> 
> Yours Sincerely
> 
> Anton Spieker
> 
> P.S.: Sorry for my bad English. I’m not a native speaker :)

As best as I can determine, this printer uses a printer language that Samsung developed for their own printers.  Gutenprint does not support that language or your printer.

Matt

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

[Protea W. J. <aik...@gm...>]

On Tue, Dec 22, 2020 at 12:37 PM Ken Smolek <ke...@sm...> wrote:

> Hi Gernot,
>
> Thanks for your quick response. I have to admit, at times I doubted that
> it would ever work. The first successful low-resolution test page was a
> tremendous relief, if only the tip of the iceberg.
>

Hello Ken,
I am happy to hear you succeeded, I know some of those feelings, though I
suspect on a smaller scale!

> If you want to take a look at what I've done, an easy way would be to
> simply tar up the gutenprint directory (about 17MB as tar .xz, including
> the git history) and find a way to send it to you.
>
OK, if you host it on say Google Drive for a day or so I can download it
from you using a shared link perhaps? Or just send to me at
aik...@gm... if attachment size is not a barrier.

> As far as curves, I did some test prints, and ended up using
> standard_hue_adjustment, standard_sat_adjustment and ip4200_lum_adjustment
> in canon-printers.h. I copied them and renamed them to Pro100_*_adjustment
> so that I can make changes. They're included in the Pro100 printer
> definition. I don't think I actually tried the MP450 adjustments, but I
> probably should.
>
The MP450 is actually for a printer model I own, and wanted to experiment
with. The standard and iP4200 curves do not work well on it. But owing to
time limitations the printer is not calibrated so the curves are not fixed
at the moment.

> There are some things I would like to do to the ink handling, but I need
> to think about it a little more and discuss it with all of you. The ink
> structure used in the escp2 driver is significantly more flexible than the
> canon driver, but I'm not sure I'd want to try to incorporate it. There are
> a few tweaks that could simplify some of the driver code, I think. And I
> put a specific Pro100 structure array in print-canon.c, which has to be
> dealt with.
>
OK, I am all ears. I have (had) my own priorities, which are mostly dealt
with, apart from the rather large CD issue. So I am happy to look into
restructuring code for more flexibility (XML files would enable users to
make changes without recompilation, a policy Robert has advocated and
implemented in the Epson driver).

> I don't even have a CD player, so I'm probably not your CD guy. In fact,
> no offense intended, but I'd like to isolate the CD code as much as
> possible in other files or at least other functions so that I don't have to
> read past it every time. From what I've seen, that wouldn't be a big job.
> Same for the code which handles weaving.
>
The Pro-100 has a disk tray for DC/DVD/Bluray printing (perhaps it depends
on region? I thought all regions have these now). But there is a serious of
different CD trays, and the Pro series uses I think the M type which we
have not gotten any practical results with since we could not print on any
of this series.
My main goal initially was to get the calculations and options right, but
if you want to help with getting the code separated out into other files
that would certainly be a positive thing.
The software weaving code I am not really sure about, whether printers
actually use it or not. Maybe early models of Canon printers used it, I do
not know. So I have never touched the weaving code.
Again, if the code would benefit from separation that is fine with me.

> It sounds like it makes sense to think hard about IPP, so I'm going to
> take a look at it over the next few days and see if I can understand it. My
> main concern, having looked at the attributes returned by the Pro-100, is
> that I'm not sure how to get maximum capability out of it. What would the
> output format be: urf or pwg-raster - I presume we wouldn't want to try to
> convert to jpeg before output?
>

Maybe Robert or something more fluent in the recommended data flow can
comment on this.

Best regards,
Gernot Hassenpflug

> If anyone wants to see an example of the output from the printer, I could
> scan a couple of prints.
>
> Ken
>
>
> On 12/21/20 6:03 PM, Protea Wines Japan wrote:
>
> On Tue, Dec 22, 2020 at 9:43 AM Ken Smolek <ke...@sm...> wrote:
>
> Hello Ken,
> Many thanks for your message, I am very impressed and delighted that you
> have managed to get one of the Pro series working.
> I am the current maintainer for the Canon backend, and would love to work
> together to incorporate the code.
>
> 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?
>>
>
> Where did you get the "standard Canon" curves from?
> I don't know how the existing ones are generated actually, there are 3 to
> choose from.
> Those for the iP4200 are apparently tuned to that printer, and may be
> correct for some other printer models too.
> Unless one actually has a printer to test, it is not really possible to
> design matrices.
> The Canon driver started out as a fork of the (now much more advanced)
> Epson driver.
>
> Robert, is there any background on the matrices in the Epson driver that
> may help?
>
> 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.
>>
>
> I would like to incorporate the code if possible. I have some
> understanding of the Canon driver code, since I have been touching it for
> some years, but I do not have a very clear understanding of ink handling
> and low-level routines even now unfortunately.
> Most of my work has been trying to add commands, and various options for
> the commands.
> A major work in progress is to get CD printing to work systematically, so
> if you have time on your hands, I would love some help with that.
>
> 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.
>>
>
> Robert, do you have any opinions on this?
>
> Best regards,
> Gernot Hassenpflug
>
>
> _______________________________________________
> Gimp-print-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>


-- 
Protea Wines Japan
Tel: 070-5550-9076
https://www.proteawines.jp

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

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

Hi Gernot,

Thanks for your quick response. I have to admit, at times I doubted that 
it would ever work. The first successful low-resolution test page was a 
tremendous relief, if only the tip of the iceberg.

If you want to take a look at what I've done, an easy way would be to 
simply tar up the gutenprint directory (about 17MB as tar .xz, including 
the git history) and find a way to send it to you.

As far as curves, I did some test prints, and ended up using 
standard_hue_adjustment, standard_sat_adjustment and 
ip4200_lum_adjustment in canon-printers.h. I copied them and renamed 
them to Pro100_*_adjustment so that I can make changes. They're included 
in the Pro100 printer definition. I don't think I actually tried the 
MP450 adjustments, but I probably should.

There are some things I would like to do to the ink handling, but I need 
to think about it a little more and discuss it with all of you. The ink 
structure used in the escp2 driver is significantly more flexible than 
the canon driver, but I'm not sure I'd want to try to incorporate it. 
There are a few tweaks that could simplify some of the driver code, I 
think. And I put a specific Pro100 structure array in print-canon.c, 
which has to be dealt with.

I don't even have a CD player, so I'm probably not your CD guy. In fact, 
no offense intended, but I'd like to isolate the CD code as much as 
possible in other files or at least other functions so that I don't have 
to read past it every time. From what I've seen, that wouldn't be a big 
job. Same for the code which handles weaving.

It sounds like it makes sense to think hard about IPP, so I'm going to 
take a look at it over the next few days and see if I can understand it. 
My main concern, having looked at the attributes returned by the 
Pro-100, is that I'm not sure how to get maximum capability out of it. 
What would the output format be: urf or pwg-raster - I presume we 
wouldn't want to try to convert to jpeg before output?

If anyone wants to see an example of the output from the printer, I 
could scan a couple of prints.

Ken


On 12/21/20 6:03 PM, Protea Wines Japan wrote:
> On Tue, Dec 22, 2020 at 9:43 AM Ken Smolek <ke...@sm... 
> <mailto:ke...@sm...>> wrote:
>
> Hello Ken,
> Many thanks for your message, I am very impressed and delighted that 
> you have managed to get one of the Pro series working.
> I am the current maintainer for the Canon backend, and would love to 
> work together to incorporate the code.
>
>     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?
>
>
> Where did you get the "standard Canon" curves from?
> I don't know how the existing ones are generated actually, there are 3 
> to choose from.
> Those for the iP4200 are apparently tuned to that printer, and may be 
> correct for some other printer models too.
> Unless one actually has a printer to test, it is not really possible 
> to design matrices.
> The Canon driver started out as a fork of the (now much more advanced) 
> Epson driver.
>
> Robert, is there any background on the matrices in the Epson driver 
> that may help?
>
>     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.
>
>
> I would like to incorporate the code if possible. I have some 
> understanding of the Canon driver code, since I have been touching it 
> for some years, but I do not have a very clear understanding of ink 
> handling and low-level routines even now unfortunately.
> Most of my work has been trying to add commands, and various options 
> for the commands.
> A major work in progress is to get CD printing to work systematically, 
> so if you have time on your hands, I would love some help with that.
>
>     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.
>
>
> Robert, do you have any opinions on this?
> Best regards,
> Gernot Hassenpflug
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

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.

Re: [Gimp-print-devel] printer driver for deskjet 932C

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

> On Dec 21, 2020, at 11:29 AM, Tony Peter <ant...@gm...> wrote:
> 
> Is there a printer driver for HP Deskjet 932C that works on Mac OS 10.13?
> 
> A reply would be appreciated.
> 
> Tony

Yes, there is a driver for that printer in the Gutenprint package.  You can download it from:
https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.3/gutenprint-5.3.3_rev.dmg/download

Matt

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

[Protea W. J. <aik...@gm...>]

On Tue, Dec 22, 2020 at 9:43 AM Ken Smolek <ke...@sm...> wrote:

Hello Ken,
Many thanks for your message, I am very impressed and delighted that you
have managed to get one of the Pro series working.
I am the current maintainer for the Canon backend, and would love to work
together to incorporate the code.

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?
>

Where did you get the "standard Canon" curves from?
I don't know how the existing ones are generated actually, there are 3 to
choose from.
Those for the iP4200 are apparently tuned to that printer, and may be
correct for some other printer models too.
Unless one actually has a printer to test, it is not really possible to
design matrices.
The Canon driver started out as a fork of the (now much more advanced)
Epson driver.

Robert, is there any background on the matrices in the Epson driver that
may help?

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.
>

I would like to incorporate the code if possible. I have some understanding
of the Canon driver code, since I have been touching it for some years, but
I do not have a very clear understanding of ink handling and low-level
routines even now unfortunately.
Most of my work has been trying to add commands, and various options for
the commands.
A major work in progress is to get CD printing to work systematically, so
if you have time on your hands, I would love some help with that.

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.
>

Robert, do you have any opinions on this?

Best regards,
Gernot Hassenpflug

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

[Robert K. <rl...@al...>]

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.

[Gimp-print-devel] Canon Pro-100

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

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

[Gimp-print-devel] printer driver for deskjet 932C

[Tony P. <ant...@gm...>]

Is there a printer driver for HP Deskjet 932C that works on Mac OS 10.13?

A reply would be appreciated.

Tony

[Gimp-print-devel] Driver for Samsung CLX-series

[Anton S. <ant...@ho...>]

Hello,

I’ve been searching very long for a driver, that works with the Samsung CLX-3185.
I would be very happy, if you could integrate this printer.

Yours Sincerely

Anton Spieker

P.S.: Sorry for my bad English. I’m not a native speaker :)

[Gimp-print-devel] Gutenprint / iOS Airprint Canon Selphy CP1000

[Gritty D. <da...@gm...>]

Hi,

Amazing work on gutenprint, I can get almost anything to work on my RPi
server. However:

I have a Canon Selphy CP1000, I can print to it from OSX when I share the
printer on the RPi with gutenprint/cups but I'd also like to print from an
iOS device (that's where the most of the photo's are)

But the driver for the CP1000 does not support page selection so it sends
the wrong format to my CP1000 and it will not print. On OSX I can select
paper size.

IS there a way to get paper sizes into this driver? I know  how to
compile stuff but where to get started on modifying a driver?

Kind regards,
Gerrit

Re: [Gimp-print-devel] HP LaserJet 4

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

> On Dec 20, 2020, at 7:05 PM, Doug Frenette <fre...@gm...> wrote:
> 
> First things first - I love this printer and will do pretty much whatever I can to keep it happily operating.  It’s part of me having been with me from brand new about 40 years ago until Mac Big Sur.  The last time I had issues I installed a generic post script printer driver.  Now I seem helpless.  Do you have any pending drivers for the HP LaserJet $4?


Yes there is a driver for that.  Use the LaserJet 4 driver for that.  You might also want to try the LaserJet 5 driver.  You can download the latest drivers from 
https://sourceforge.net/projects/gimp-print/files/gutenprint-5.3/5.3.3/gutenprint-5.3.3_rev.dmg/download

Matt

[Gimp-print-devel] HP LaserJet 4

[Doug F. <fre...@gm...>]

First things first - I love this printer and will do pretty much whatever I can to keep it happily operating.  It’s part of me having been with me from brand new about 40 years ago until Mac Big Sur.  The last time I had issues I installed a generic post script printer driver.  Now I seem helpless.  Do you have any pending drivers for the HP LaserJet $4?

Forever in your debt,
Doug Frenette
Calgary, Alberta
Canada

Re: [Gimp-print-devel] Driver for HP Officejet 4500 G510

[Robert K. <rl...@al...>]

On 12/19/20 7:48 PM, Alan Knight wrote:
> Hello,
> Do you have a driver that will allow my HP Officejet 4500 G510 to work on Mac OS 11.1?

It's possible that one of the existing drivers will work (most likely OfficeJet 500, OfficeJet 700,
OfficeJet G55, OfficeJet Pro 1150C, OfficeJet R40, or OfficeJet LX -- all of the OfficeJet printers
we support use one of those drivers).  Otherwise, we do not currently have anyone maintaining this
driver, so we're not going to be able to support it unless someone steps up.

[Gimp-print-devel] Driver for HP Officejet 4500 G510

[Alan K. <an...@tw...>]

Hello,
Do you have a driver that will allow my HP Officejet 4500 G510 to work on Mac OS 11.1?

Thank You,
Alan Knight
Columbia, SC

[Gimp-print-devel] Request for documentation

[Andre C. <and...@vi...>]

Hello,

I am using gutenprint version 5.2.9 on Gimp 2.10 and Windows 10.I am 
trying with some success to print in black and white (greyscale) with MS 
six tone. Would it be possible to have more documentation on how to set 
the values of the "Hextone Gray (1 to 5) Transition" parameters. The 
instructions in the documentation manual lack a lot of clarity on this 
topic and I can't find any on Google.

I thank you very much,

André

Re: [Gimp-print-devel] printer drivers and macos Big Sur

[Robert K. <rl...@al...>]

On 12/18/20 11:43 AM, Matt Broughton wrote:
> 
> 
>> On Dec 18, 2020, at 9:38 AM, David Kurtz <ku...@ic...> wrote:
>>
>> Hi Mike:
>>
>> As I’ve said, I have HP OfficeJet 4620.
>> Can you recommend that I install 5.3.3?
>>
>> Thanks,
>> David K
> 
> I don't see where there is any support for a generic pcl3 printer. Even if there were, it would most likely be tailored for a laser printer and not have support for color printing.   Given that, I cannot "recommend" installing it.  If you want, of course you can install it and give it a go.

The gneric color driver may work for this.

Re: [Gimp-print-devel] printer drivers and macos Big Sur

[Richard S. <ras...@sl...>]

In case you didn't get it the first time:

I have just checked the HP site and they list a driver for this printer 
for MacOS 11, which I believe is Big Sur:

https://support.hp.com/us-en/drivers/selfservice/hp-officejet-4620-e-all-in-one-printer-series/5101229/model/5101234


David Kurtz via Gimp-print-devel wrote:
> OK, fair enough. Any plans for adding support for the HP Officejet 4620 in future driver release?
> 
> David
> 
>> On Dec 18, 2020, at 8:43 AM, Matt Broughton <wal...@ma...> wrote:
>>
>>
>>
>>> On Dec 18, 2020, at 9:38 AM, David Kurtz <ku...@ic...> wrote:
>>>
>>> Hi Mike:
>>>
>>> As I’ve said, I have HP OfficeJet 4620.
>>> Can you recommend that I install 5.3.3?
>>>
>>> Thanks,
>>> David K
>>
>> I don't see where there is any support for a generic pcl3 printer. Even if there were, it would most likely be tailored for a laser printer and not have support for color printing.   Given that, I cannot "recommend" installing it.  If you want, of course you can install it and give it a go.
>>
>> Matt
>>
>>>
>>>> On Dec 16, 2020, at 6:21 PM, Matt Broughton <wal...@ma...> wrote:
>>>>
>>>>
>>>>
>>>>> On Dec 16, 2020, at 10:37 AM, David Kurtz via Gimp-print-devel <gim...@li...> wrote:
>>>>>
>>>>> Hello;
>>>>>
>>>>> My new computer is running MacOS Big Sur. I have an older HP printer connected to it via USB. It no longer works. HP has not updated their drivers. Apple has no solution.
>>>>>
>>>>> I checked gimp-print website for MacOS. Do you have any reports of gutenprint-5.3.3 addressing that problem?
>>>>>
>>>>> Thanks,
>>>>> David K
>>>>
>>>> David, we will at least need the model of your HP printer.  You can find a list of the printers Gutenprint does support here:
>>>> http://gimp-print.sourceforge.net/p_Supported_Printers.php
>>>>
>>>> Matt
>>>>
>>>>
>>>
>>
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>