GIMP PDF export plugin

[Alexandre Prokoudine]

On Sun, Mar 22, 2009 at 11:13 PM, peter sikking wrote:

> so now we really need some trend spotting from those in our community
> who deal with serious printing jobs.

It's difficult to talk about trends with regards to printing industry
which tends to be quite conservative.

If you tell Scribus guys "My printer demands TIFF" they will most
likely reply "Then you bloody well find another printer". Except there
can be no other printer. Just two weeks ago I've heard from two
different people: for the first guy there was no printer in his area
to do color trapping on-site, so they asked him to do it himself, and
no free DTP software supports it; for the second guy the printer
demanded CDR (native Corel files) instead of PDF.

Point of fact: a really good application should be implying the least
dangerous workflow (which is definitely PDF based) while supporting
all kinds of perversions.

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Guillermo Espertino]

I send files to print shops every week. Here in argentina even serious
printers require proprietary file formats like AIs and CDR, though
they're fine with tiffs and PDFs.
I don't understand why there is so much interest in supporting PDF
export from GIMP, since the exported data will be only bitmap, and in
that case a tiff file is enough and is absolutely compatible with every
design program out there.
In my oppinion, PDF only makes sense if there is mixed data like bitmap
images and vector shapes or text. For flattened bitmaps, I'd say TIFF is
even safer than PDF.
My current workflow consists in separate RGB images to a CMYK tiff using
the Separate+ Plugin. Usually I do some black overprint tweaking using
the faux channels that Separate+ creates.
When I need a PDF, I use Scribus or this
script:http://my.opera.com/area42/blog/cmyk-tiff-2-pdf-for-gimp

I think PDF will only make sense when vector shapes, CMYK color and spot
channels are in GIMP.
Meanwhile, Separated Tiffs are enough and I think that putting time and
efforts on a PDF exporter wouldn't make a real difference.

I'd prefer to see the separate plugin integrated in gimp, direct save of
the separated tiff through the save plugin, importing separated tiffs
directly (opening CMYK tiffs currently results in an uncorrected image
with distorted colors wich is pretty unusable).

So -1 to this. There are oteher things far more important than this.

Gez.


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Chris Mohler]

2009/3/22 peter sikking <peter@...>:

> Sven wrote:
>
>>> bummer about the non-standard, but would industrial-strength TIFF
>>> in and export not be significantly more in line with our product
>>> vision than industrial-strength pdf in and export?
>>
>> Depends on what gets used nowadays. If professionals are turning away
>> from TIFF and start to adopt PDF instead, then PDF support would be
>> more
>> in line with our product vision.
>
>
> when I wrote the previous message I already knew that this is the
> only counter-argument that I was going to accept.
>
> so now we really need some trend spotting from those in our community
> who deal with serious printing jobs.

I often use GIMP as a part of my work flow - but almost never for
preparing the final artwork for submission to the printing company -
mainly due to the aforementioned lack of CMYK color space.

Only ~1% of my PDF files submitted to printing companies are 100%
raster.  PDF seems (to me) to be gaining ground against formats like
TIFF, but it's not a "standard" yet (for raster images anyway).  On
one hand, TIFF is still more widely accepted than PDF.  On the other
hand, PDF is well documented.  On the gripping hand, neither format is
useful for print jobs without the CMYK color space - which I know is
somewhat arbitrary, but many printing companies expect files in CMYK.
If I have a choice, I use TIFF or PNG for raster pre-press images -
but it might be wise to look to the future: PDF format has options
(like crop area and bleed) that are useful to printers and the format
seems to be slowly catching up to the "standards" (at least in my
experience over the past few years in the US).

> and when then moving forward with pdf, we should keep in mind
> what a GIMP document actually is: a single canvas/image
> (please do not mention the animation hacks we have...)

You and I are in 100% agreement on this point ;)

So to recap, I would welcome a printer-friendly PDF export if someone
wants to work on it, though without CMYK support built-in it's not
very useful just yet.  From what I understand though, once GEGL
integration is complete, any plugin could be refactored or rewritten
to use higher bit depth and other color spaces.

Chris
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Mon, 2009-03-23 at 14:31 -0500, Chris Mohler wrote:

> So to recap, I would welcome a printer-friendly PDF export if someone
> wants to work on it, though without CMYK support built-in it's not
> very useful just yet.  From what I understand though, once GEGL
> integration is complete, any plugin could be refactored or rewritten
> to use higher bit depth and other color spaces.

We don't plan to support editing images in CMYK. But what you need to
get your images printed is a color separation based on the RGB and
printer CMYK color profiles. This can very well be part of a PDF export
plug-in. The separate+ plug-in shows how this can be done for TIFF
files.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Sven Neumann wrote:
> We don't plan to support editing images in CMYK.
>
> Sven
>  

The product vision states that "GIMP is a high-end photo manipulation
application" and that certainly includes support for editing images in
the CMYK color space. We can't call ourselves high-end without that
support. I, for one, have plans to implement support for CMYK editing,
but that is quite far into the future.

- Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote:

> The product vision states that "GIMP is a high-end photo manipulation
> application" and that certainly includes support for editing images in
> the CMYK color space.

It certainly doesn't. Photos are taken in an RGB color space. It makes
sense to do some processing in other color spaces such as LAB. But CMYK
is totally inadequate for manipulating photos.

Being able to do a color separation to CMYK is sometimes required in
order to prepare an image for print (even though the printer can almost
always do this much better). Editing an image in CMYK is not required
though.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Sven Neumann wrote:

> On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote:
>  
>> The product vision states that "GIMP is a high-end photo manipulation
>> application" and that certainly includes support for editing images in
>> the CMYK color space.
>>    
>
> It certainly doesn't. Photos are taken in an RGB color space. It makes
> sense to do some processing in other color spaces such as LAB. But CMYK
> is totally inadequate for manipulating photos.
>  

Photos are usually taken in the RGB color space, but usually printed in
the CMYK color space. Support for editing in both these color spaces is
to me clearly within the scope of a high-end photo manipulation application.

Yes, processing shall as long as possible be done in RGB, but at some
point you need to convert to the CMYK color space and a high-end photo
app should support editing also in this color space.

- Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote:

> Yes, processing shall as long as possible be done in RGB, but at some
> point you need to convert to the CMYK color space and a high-end photo
> app should support editing also in this color space.

Why? Because you say so? All high-end photo editing applications are
pushing for an RGB only work-flow these days. There is no need to do any
editing in CMYK. If you really want to insist that being able to edit
CMYK is needed and that developer resources should be spent on it, then
you should at least give a compelling reason.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Chris Mohler]

On Mon, Mar 23, 2009 at 2:57 PM, Sven Neumann <sven@...> wrote:

> Hi,
>
> On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote:
>
>> The product vision states that "GIMP is a high-end photo manipulation
>> application" and that certainly includes support for editing images in
>> the CMYK color space.
>
> It certainly doesn't. Photos are taken in an RGB color space. It makes
> sense to do some processing in other color spaces such as LAB. But CMYK
> is totally inadequate for manipulating photos.
>
> Being able to do a color separation to CMYK is sometimes required in
> order to prepare an image for print (even though the printer can almost
> always do this much better). Editing an image in CMYK is not required
> though.

It is helpful to see an approximation of CMYK on the screen before you
go to print - many colors available in the RGB color space fall
outside of the CMYK gamut.  RGB blue is likely the worst offender -
fill an image with solid #0000FF and print it to a color printer and
you will see quite a shift in color.

Take a simple case: annotating a photo with some text (for print use)
- working in CMYK space would prevent the user from using #0000FF as
the text color (or actually convert it from #0000FF to its CMYK equiv
on the fly) - giving a reasonably accurate representation of the final
printed output on the screen.

A more complicated case: removing small black text from the CMY
channels manually (to improve legibility) - or more realistically only
applying the small text to the K channel.  Editing the channels in
CMYK would be more comfortable than running through the separation
process first and then making changes - and the ability to use CMYK
swatches (in this case C=0, M=0, Y=0, K=100) could also speed things
up dramatically.

Of course this is not a trivial task, and I'm not holding my breath.
Although it might not be hard to throw up a projection of the current
image with a generic CMYK profile applied to it - that would be enough
to satisfy the simple use-case above.  Oh, and I guess we're rapidly
drifting off-topic in re to PDF export ;)

Chris
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Sven Neumann wrote:

> On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote:
>> Yes, processing shall as long as possible be done in RGB, but at some
>> point you need to convert to the CMYK color space and a high-end photo
>> app should support editing also in this color space.
>>    
>
> Why? Because you say so? All high-end photo editing applications are
> pushing for an RGB only work-flow these days. There is no need to do any
> editing in CMYK. If you really want to insist that being able to edit
> CMYK is needed and that developer resources should be spent on it, then
> you should at least give a compelling reason.
>  

I am by no means a photography professional and my point of view comes
mostly from what other people have said regarding CMYK support; I don't
have any direct sources to give.

Could you perhaps clarify/give references to your claim that high-end
photo editing apps are pushing for an RGB only work-flow? If you are
going to print an image, CMYK _will_ play a role in your work-flow.

- Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[D. Stimits]

Some parts of this message have been removed. Learn more about Nabble's security policy.

FYI, my company writes most of its own output in PostScript for high end laser printers (e.g., Xerox I-GEN 3 and 4). We avoid CMYK. But we're not a pre-canned application company, we write everything ourselves. All of our printers work great with RGB colorspace. The need for CMYK is usually based on the software that goes with the printer or the shop's chosen software helper applications. I suspect that CMYK in the laser printer market is just something passed on from wet press. However, people often send CMYK art to us, and we need the ability to import CMYK into RGB.

About PDF: PDF has some of its own drawing language, but when it comes to raster, it simply embeds bitmaps. That imbedded bitmap can be an almost exact copy of tiff, png, gif, whatever. PDF is a hybrid vector language with embedded bitmap. I'd love the ability to import or export with PDF pages translated to/from layers.

And kudos to gimp for having the best quality PostScript. Gimp outputs valid PostScript, which I can't say the same for on most Adobe products. PDF used to be a proprietary thing, where Adobe made readers free, and writers pay, but they turned it into an open standard and anyone is free to do whatever they want these days. I'd trust gimp to do a better job at a PDF implementation than I would Adobe.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Mon, 2009-03-23 at 15:27 -0500, Chris Mohler wrote:

> It is helpful to see an approximation of CMYK on the screen before you
> go to print - many colors available in the RGB color space fall
> outside of the CMYK gamut.  RGB blue is likely the worst offender -
> fill an image with solid #0000FF and print it to a color printer and
> you will see quite a shift in color.

GIMP already provides that. You can ask for a Soft Proof and it will
show you an approximation of what will be printed based on the CMYK
printer profile you specified. It can also show you out-of-gamut colors.

> Take a simple case: annotating a photo with some text (for print use)
> - working in CMYK space would prevent the user from using #0000FF as
> the text color (or actually convert it from #0000FF to its CMYK equiv
> on the fly) - giving a reasonably accurate representation of the final
> printed output on the screen.

In order to do that, all you need is to be able to select an RGB color
by specifying the CMYK values (and of course you should get exactly that
CMYK color then as a result of the RGB->CMYK conversion). You can
already do that. If you specify a CMYK profile, the CMYK color selector
will make use of that.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

On Mon, Mar 23, 2009 at 11:49 PM, Sven Neumann wrote:

> GIMP already provides that. You can ask for a Soft Proof and it will
> show you an approximation of what will be printed based on the CMYK
> printer profile you specified. It can also show you out-of-gamut colors.

Last time I did a softproof in GIMP I ended up with darker and less
saturated prints. So I did a simple test --- captured screenshots of a
window holding "normal" view of a photo and a "softproof", then merged
them into a multilayer image and changed softproof shot's layer mode
to "difference". Everything except just few pixels was black. I was
probably doing something really stupid, but to me it sounded like
softproof was broken. It was fairly recently and I didn't have time to
write a proper report (and I didn't try that with other photos). If
you are interested, I still could do that.

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Alexandre Prokoudine wrote:

> On Mon, Mar 23, 2009 at 11:49 PM, Sven Neumann wrote:
>  
>> GIMP already provides that. You can ask for a Soft Proof and it will
>> show you an approximation of what will be printed based on the CMYK
>> printer profile you specified. It can also show you out-of-gamut colors.
>>    
>
> Last time I did a softproof in GIMP I ended up with darker and less
> saturated prints. So I did a simple test --- captured screenshots of a
> window holding "normal" view of a photo and a "softproof", then merged
> them into a multilayer image and changed softproof shot's layer mode
> to "difference". Everything except just few pixels was black. I was
> probably doing something really stupid, but to me it sounded like
> softproof was broken.

This doesn't say much about soft-proof being broken or not, it depends
on many things such as the accuracy of the color profile, the image
itself, and the rendering intent that was used.

- Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Andrew A. Gill]

On Mon, 23 Mar 2009, Martin Nordholts wrote:
>
> I am by no means a photography professional and my point of view comes
> mostly from what other people have said regarding CMYK support; I don't
> have any direct sources to give.
>
> Could you perhaps clarify/give references to your claim that high-end
> photo editing apps are pushing for an RGB only work-flow? If you are
> going to print an image, CMYK _will_ play a role in your work-flow.

I do work in the printing industry, and I can tell you that
output is still CMYK, and will remain CMYK for at least the next
few years.  Well, some of it is 6-color Hexachrome.

And the newest technology is digital presses like the HP Indigo,
which are also 6-color or more.  The cheap ones cost upwards of
$160,000, not counting the product maintenance contract.  No one
is going to turn around and buy another press that uses a
completely different workflow after dropping that much money on a
brand new press just 4 years ago.

I have seen no evidence that anyone is moving from a CMYK or
6-color workflow to an all-RGB workflow.  I do know that some
desktop printers use RGB color inputs, but those are desktop
printers, not professional presses.

The workflow may be different for photo editing than for some of
the documents that I work on (most are spot jobs, but some
involve image manipulation), especially with things like photo
kiosks, but professional-quality press output will remain CMYK
for quite some time.

I recognize that CMYK editing is a difficult thing, and I'd
encourage you to take the time to do it right, but I'd also
encourage you to do it.  It may take some work to convert current
Adobe users to GIMP, but the way GIMP works now, you ensure that
they can't even consider it.

Full disclosure: I use Adobe products at work, but GIMP at home.
I much prefer the UI of GIMP to that of Photoshop, and it works
just fine for the amateur work that I enjoy as a hobby at home.
In fact, GIMP can do all the professional things that I need it
to at work--all except CMYK and spot.  I don't even really use
16-bit much, and I can work around PMS colors.

If GIMP had CMYK support, I could take my work home.

--
| Andrew A. Gill     To ensure continued quality of service,   |
|                    this e-mail is being monitored by the NSA |
| <superluser@...> <http://www.needsfoodbadly.com> |
                                                               --
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

Sven wrote:

> Martin wrote:
>> Yes, processing shall as long as possible be done in RGB, but at some
>> point you need to convert to the CMYK color space and a high-end  
>> photo
>> app should support editing also in this color space.
>
> Why? Because you say so?

wow, the return of the cmyk wars.

the photo part is not the issue, the vision also speaks of

"GIMP [...] supports creating original art from images"

I agree with the point that all of GIMP should be pure rgb
based, with support for cymk import, export and cymk color selection.

let me quote myself from 2 weeks ago about managing and checking and
optimising export to lossy formats:

"my rough plan for supporting that looks like overlaying the
image with a projection screen (lets not call it a layer)
that simulates the lowering of fidelity. then this projection
screen itself could contain several layers of optimisations
and corrections that users may want to take. the high fidelity
image data is still available for further development.

"bonus:

"that recent ars technica review had a really clarifying metaphor
for cmyk for print workflows. along the lines of: the cmyk file
is the LP pressing of the rgb master tape. seeing this cmyk
conversion as a fidelity reducing (colour gamut) 1-way conversion,
it looks like the projection screen plan above could be the beginning
of a working cmyk support solution."

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Mon, 2009-03-23 at 17:51 -0400, Andrew A. Gill wrote:

> I do work in the printing industry, and I can tell you that
> output is still CMYK, and will remain CMYK for at least the next
> few years.

Output, yes, of course. But where in this process do you actually edit
an image in CMYK? I don't mean converting it to CMYK to get it printed.
I mean actual editing after the conversion. Could you give us some
examples of where that is needed?


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Guillermo Espertino]

CMYK exists because, though is possible theoretically, it isn't possible
to generate black from mixing CMY inks. As the C, M and Y inks aren't
perfect and have some contaminants, mixing them ends up in a dirty brown
instead of pure black.
That's why CMYK exists, and that's why it isn't so simple to print an
RGB image.
The problem resides mostly in the generation of black and gray shades.
Although there are systems that do a great job converting a photo to
CMYK on the print side, it's still a problem to do a simple task as
placing a pure black overprint on a solid color background without
destroying some underlaying information on the separation.
I'm a designer, not a photographer, and an image manipulation program is
an essential part of my workflow. And placing some black text, or
editing a large image with a black or gray background, adding black drop
shadows, aren't rare at all. And it's a pain without the ability of
editing the separated CMYK.
It's not about if the printer will handle the file or not, is about
creative control. Sometimes you NEED to control the black overprint.
Sometimes you need to use spot colors and you need to control the
channels and how they overprint.
Even with Adobe software, before having spot channels in Photoshop, it
was a common practice to separate to CMYK to make 2, 3 or for 2 inks
prints (replacing the corresponding plate's ink for a custom ink).
Simply because other programs didn't support the Adobe's custom
multitone files but did support CMYK tiffs.

Well, I can't do duotones with Gimp to insert in a 2 inks flyer.
CMYK editing would help. I can't control the black generation of a
separation, because the separate+ plugin doesn't support that. It just
support existing profiles and there is no control. I can't control CMYK
curves. And trust me, that's extremely common.

I can live without CMYK, I have some workarounds and can do some tricks,
but it certainly makes my designer work harder and less productive.
I can wait, I'm ok with the argument "it's not trivial, requires a lot
of work, requires a lot of refactoring". But I'm not ok when somebody
says that it isn't necessary.
Maybe it isn't for photographers, but it certainly is for designers.
GIMP stands for GNU Image Manipulation Program. Not just for Photograpy.
I think that CMYK editing is certainly in the scope of the product
vision.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Robert Krawitz-2]

   From: Sven Neumann <sven@...>
   Date: Mon, 23 Mar 2009 23:18:23 +0100

   On Mon, 2009-03-23 at 17:51 -0400, Andrew A. Gill wrote:

   > I do work in the printing industry, and I can tell you that
   > output is still CMYK, and will remain CMYK for at least the next
   > few years.

   Output, yes, of course. But where in this process do you actually
   edit an image in CMYK? I don't mean converting it to CMYK to get it
   printed.  I mean actual editing after the conversion. Could you
   give us some examples of where that is needed?

The most obvious example to me (and this has been discussed wrt
Gutenprint and other printer drivers) is to allow printing "text
black" -- text (or similar) that should be printed with black ink,
which is usually more crisp than composite.

This is essentially a special case of a spot color.  An alternative
would be RGB+K.

My sense is that this should not be a very high priority for GIMP --
we never got around to implementing it and nobody has complained.  But
it is one possible use case for CMYK (although I think RGB+K would be
a better input space for it, anyway -- and if you're going to do that,
you might just as well generalize the spot color support).

When people do send CMYK data to Gutenprint, the large majority of the
time it's either because they don't really understand what CMYK is
(it's very device and media specific) or because we have a problem
with the GCR parameters (or some other parameter problem) for a
particular printer and CUPS's default RGB->CMYK conversion happens to
work better.

Personally, I would *much* rather see development effort go into high
bit depth support (which will do a lot of people a lot of good right
away) than CMYK editing support.  But, that's just my take.

--
Robert Krawitz                                     <rlk@...>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@...
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Hal V. Engel]

On Monday 23 March 2009 04:56:23 pm Robert Krawitz wrote
snip
>
> When people do send CMYK data to Gutenprint, the large majority of the
> time it's either because they don't really understand what CMYK is
> (it's very device and media specific) or because we have a problem
> with the GCR parameters (or some other parameter problem) for a
> particular printer and CUPS's default RGB->CMYK conversion happens to
> work better.

One other reason is that they have created custom CMYK profiles for the
printer and the color space conversion to the printer CMYK color space is
better using that profile than either what the driver or what CUPS does.  But
this is a very small set of users.  But this has nothing to do with editing of
the images.

Hal

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer