GIMP PDF export plugin

[Alexandre Prokoudine]

On Wed, Mar 25, 2009 at 10:44 PM, yahvuu wrote:

>> I can express any CMYK color in RGB - but not the other way around.
>
> now i'm confused :)
>
> Is CMYK->RGB->CMYK roundtrip safe?

It's not :) And I believe that a small portion of CMYK colors is out
of gamut for RGB too , by the way :)

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

[Martin Nordholts-2]

Alexandre Prokoudine wrote:
> It's not :) And I believe that a small portion of CMYK colors is out
> of gamut for RGB too , by the way :)
>  

Both RGB and CMYK are device dependent color spaces and without any kind
or further specification one can not say how the former relates to the
latter

You can compare for instance sRGB RGB and US Web Coated SWOP CMYK, but
not just RGB and CMYK

Sorry for nitpicking

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

[Alexandre Prokoudine]

On Wed, Mar 25, 2009 at 11:06 PM, Martin Nordholts wrote:

> Both RGB and CMYK are device dependent color spaces and without any kind
> or further specification one can not say how the former relates to the
> latter

That goes without saying :)

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

[Louis Desjardins-2]

Alexandre Prokoudine a écrit :

> On Wed, Mar 25, 2009 at 6:21 PM, Alexandre Prokoudine wrote:
>
>> 1. Client brings an image for poster in CMYK which needs color
>> correction. Urgent work, not time to ask him to redo it. Double color
>> space conversion is out of question. So he had to use Photoshop from
>> VMWare.
>>
>> 2. You have a newspaper where first page should have a two-color
>> photo: black (C=0%M=0%Y=0%K<=100%) and blue (C<=100%M=0%Y=0%K=0%).
>> separate+ however separates black to 4 channels.
>>
>> 3. Some print houses set limit to overall sum of colors, for example
>> 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a
>> little of K and Y this will result in unnatural colors in a newspaper.
>>
>> 4. Live density control for each CMYK channel is a must (Scribus/SVN
>> has that in preview dialog).
>
> I was reminded that I actually forgot
>
> 5. Part of an image should be b/w and the rest should be colorized
> with just one tint. E.g. Cyan + Black for sea. separate+ and exporting
> are of no help here.

Working in CMYK at one point in the workflow is a question of control.
You need to obtain a predictable result on press and you need to work
with what you really have, often "exactly", in terms of color
combination. When printing in color on an offset press you have 3
possibilities. a) Spot colors (blended or preblended inks that could be
just any color), b) 4-color process (CMYK inks) c) Hexachrome or 6-color
process CMKYGO.

So, pursuing with this interesting list of real-case scenario or why
can’t we just rely on RGB throughout the creation process (while I agree
some people can decide they work only with it):

6. In a layout,  you have a picture from which you want to pick a
specific color and apply it to another element in the page. You will
want to have control over that color. For instance, if this color is to
be applied on text, you will want to make sure you don’t end up with ink
in the four channels because on press you might (you probably will)
encounter registration issues with such tiny elements as the hairline
portion of a font. You will need to limit this to a 3 color
combinations. Now, how do you do this with a RGB>CMYK converter? There
has to be some human supervision in the process. So, it doesn’t matter
really if you do the whole work in GIMP instead of if you split the job
between Scribus and GIMP or Inkscape for instance: at some point you
will need to have all color elements to speak the same language and this
language will have to be the lower common denominator: CMYK.

7. You want side by side a dark background and a color image. Both can
be created in GIMP but for the dark background you will really want to
control the combination of inks that produces that specific color and
again it’s going to be difficult to just let the converter do the job
without you being in full knowledge of what’s going on behind the scene.

I realise that my examples are not purely "image" manipulation (which is
the core task of GIMP) but instead "image usage and combination" but
really, this is mostly what graphic design is all about!

8. If a user is not concerned about precision, he/she might not need
that much control over an image but if you work for an ad agency that
needs to produce tons of images that include, for instance, skin tone —
then you also need to have total control over the colors and this has to
be done in CMYK which is the very end of the workflow. In the end we
will have to turn the image into CMYK and it does really happen often
that we have to adjust colors at this far point in the workflow.

9. While prepress and press shops can handle pretty easily RGB data,
it’s going to be a "best effort" made by the RIP itself according to
curves and algoritms the designer has no control over. And I know not
many designers who will accept that. At some point, they will need both
a good converter and means to adjust the resulting image. This is
fine-tuning, I agree.

10. The packaging industry makes a great use of CMYK + Spot colors. To
convince yourself, unfold any packaging and you will notice all the
press marks on the inner flaps and the colors used. This means that both
pixel and vector driven applications need to be able to work in CMYK +
Spot if we want to address the packaging industry needs. There is quite
a lot of design there to accomplish!

I guess we could find other real life scenarios where CMYK control is
important or even stronger, a necessity.

I humbly wish this short intervention will help understand better the
needs from the print point of view.

Louis


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

[Andrew A. Gill]

On Wed, 25 Mar 2009, peter sikking wrote:

> Alexandre Prokoudine wrote:
>
>> There was a somewhat heated discussion of this thread at
>> linuxgraphics.ru forum and here are several examples from people who
>> deal with prepress work on daily basis:
>>
>> 1. Client brings an image for poster in CMYK which needs color
>> correction. Urgent work, not time to ask him to redo it. Double color
>> space conversion is out of question. So he had to use Photoshop from
>> VMWare.
>>
>> 2. You have a newspaper where first page should have a two-color
>> photo: black (C=0%M=0%Y=0%K<=100%) and blue (C<=100%M=0%Y=0%K=0%).
>> separate+ however separates black to 4 channels.
>>
>> 3. Some print houses set limit to overall sum of colors, for example
>> 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a
>> little of K and Y this will result in unnatural colors in a newspaper.
>>
>> 4. Live density control for each CMYK channel is a must (Scribus/SVN
>> has that in preview dialog).
>>
>> To me it's somewhat strange that GIMP's product vision doesn't mention
>> prepress needs explicitly.
>
> A vision is an expression of the project of what they want
> the software to be.
>
> There is choice in there, and the user community cannot demand
> that GIMP does certain things. For instance making web mockups
> (including the required html + css generation) is explicitly not
> supported.
>
> Now what about that prepress. I think it is fairly safe to say
> that scribus' vision is to be prepress-king and GIMP should watch
> it not to want to overlap too much in that department. Everything
> in the above examples that reeks of newspaper, publications or
> multiple pages is a job for scribus. They want to do this.

Scribus is vector-based, not raster based.

I do not believe that Scribus has any intent to be allow
raster-based editing, but I could be wrong.

I have CC'd the Scribus list.  Let us hear their opinions.  Does
Scribus intend to allow people to tackle the problems listed
above?

Or would you be able to trap the following image with Scribus?

<http://www.ets.ru/images/pk000075.jpg>

> The vision does speak about creating original art and I am all for
> it to bring this original art to the printing press. And not via
> the print dialog (I am also mr. openPrinting) but those printing
> presses that have operators. From the description above you can
> see what is should be like: first you create the art, then you
> bring it to the press. Mix master tape (in rgb) and then cut
> the lp (in cmyk).

As someone who works in prepress, I can tell you that when we
take it from original artwork to press, we have to run any raster
artwork through Photoshop or a competing product.

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

[Andrew A. Gill]

On Wed, 25 Mar 2009, Alexandre Prokoudine wrote:

> On Wed, Mar 25, 2009 at 7:27 PM, Andrew A. Gill wrote:
>
>> Agreed.  I don't think anyone here is looking for a Photoshop clone (I know
>> that I personally hate PS for a variety of reasons), but we do realize that
>> it has to compete with Photoshop, and not addressing the issues of large
>> sections of the design market when your competitor does is probably not the
>> best move.
>
> Do we realize that? :)
>
> It is true that GIMP is usually seen as to-be-photoshop-substitution
> and its maturity in various areas in fact is the reason why people
> switch to GIMP. However GIMP doesn't seem to be driven by a will to
> make Photoshop die, die, die :)

<http://www.businessdictionary.com/definition/competitor.html>

It's a product that has similar features.  It's a competing
product.

(Personally, I want to make Photoshop die, die, die, but that's
mainly because of a deep loathing for the UI.)

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

[Graeme Gill]

peter sikking wrote:

> Now what about that prepress. I think it is fairly safe to say
> that scribus' vision is to be prepress-king and GIMP should watch
> it not to want to overlap too much in that department. Everything
> in the above examples that reeks of newspaper, publications or
> multiple pages is a job for scribus. They want to do this.

As I understand it, Scribus is not a pixel editor, it is
a page layout package, rather a different thing altogether.

So you're saying that Scribus should add a pixel editing
package to their application, so that they can support CMYK
and other non-RGB color spaces, duplicating an awful lot
of what's in GIMP ?

> The vision does speak about creating original art and I am all for
> it to bring this original art to the printing press. And not via
> the print dialog (I am also mr. openPrinting) but those printing
> presses that have operators. From the description above you can
> see what is should be like: first you create the art, then you
> bring it to the press. Mix master tape (in rgb) and then cut
> the lp (in cmyk).

I really don't think people working in the graphic
arts are going to want to master two different pixel editing
packages, simply because one of them doesn't support anything
other than RGB. If they're in the Linux sphere, then I guess
they need to go and look at using Krita instead.

[ ie. handling CMYK and other colorspaces is a superset
  capability, with RGB being a subset, and the colorspace is orthogonal
  to the pixel manipulation capabilities ]

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

[Andrew A. Gill]

On Thu, 26 Mar 2009, Graeme Gill wrote:
>
> As I understand it, Scribus is not a pixel editor, it is
> a page layout package, rather a different thing altogether.

For the record, Scribus does allow pixel editing.

When you right click on an image and select Edit Image, it opens
the image in GIMP.

I think that's pretty strong evidence that there's no intent to
do raster editing in Scribus itself.

> I really don't think people working in the graphic
> arts are going to want to master two different pixel editing
> packages, simply because one of them doesn't support anything
> other than RGB. If they're in the Linux sphere, then I guess
> they need to go and look at using Krita instead.

FYI, Krita is extremely buggy.  It has an SDI, which some people
(e.g. me) don't like, but the code will improve and there may be
improvements in the interface.  Krita may indeed surpass GIMP.
Sad, really, since I think GIMP can be the better product.

[from here out, `you' refers to core GIMP developers]

We want you to succeed, and all you need to do to succeed is to
address some of the issues that users need.  If you're telling us
that GIMP has no intention of ever providing those things, we'll
find another product.  Maybe Krita when it becomes vaguely
stable, or maybe a fork.

But you've got the time to do it before the others catch up, and
you've got GEGL, the toolset to do it right.

Here's a thought: I can code.  I'm sure others on this list can,
too.  Why don't you tell us what you would require for a CMYK
mode to be incorporated into the trunk of GIMP.  We can all read
the API, but you can tell us what coding standards we need, what
toes we can't step on and why other attempts to add similar
functionality (like Cinepaint nee FilmGimp) foundered, and what
we can do to avoid making those same mistakes.

If you tell us what we need to do, we can do it.  That's the
point of Open Source!

If you don't, people are going to get sick of the excuses and
simply move on to develop this functionality somewhere else.

>From the outside, GIMP is seen as a shining example of what open
source is capable of.  Inside the OSS movement, it's seen much
like the XFree86 guys--constantly bickering about the same
issues.  I'm sure that you'd have no trouble getting developers
to work on a flagship product if they were convinced that it
would end some of the internal conflicts in OSS.

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

[Guillermo Espertino]

Even though I agree that most of the CMYK cases mentioned use CMYK
almost as spot colors, I can think of a very common usage scenario in
Graphic Design where you need to be able to edit CMYK directly:

Corporate colors.
Most frequently Pantones. Brands have their corporate colors and ask
designers to use them, but they can not always afford extra spot passes
in offset press, so the colors have to be converted to the most
aproximate CMYK combination (the Pantone Bridge catalog is for that).

So you have to adjust the color of a photograph of a sign, a truck and a
producto of your client to their corporate CMYK color.

It's a photograph, you need CMYK, you can't use spot.

This is a very common scenario, and it's a task for a image manipulation
program.

Gez.

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

[Andrew A. Gill]

On Wed, 25 Mar 2009, Guillermo Espertino wrote:

> Even though I agree that most of the CMYK cases mentioned use CMYK
> almost as spot colors, I can think of a very common usage scenario in
> Graphic Design where you need to be able to edit CMYK directly:
>
> Corporate colors.
> Most frequently Pantones. Brands have their corporate colors and ask
> designers to use them, but they can not always afford extra spot passes
> in offset press, so the colors have to be converted to the most
> aproximate CMYK combination (the Pantone Bridge catalog is for that).
>
> So you have to adjust the color of a photograph of a sign, a truck and a
> producto of your client to their corporate CMYK color.
>
> It's a photograph, you need CMYK, you can't use spot.
>
> This is a very common scenario, and it's a task for a image manipulation
> program.

Sadly for the cause of CMYK, that's not really a good example.
That's a better example for the need for Pantone and other color
matching system support.

Which GIMP will eventually need, but I'm thinking that day will
come a decade or two from now, hopefully when there's an open
source rival for Pantone.

(I actually plan to take that task on, myself in a few years, as
part of some research)

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

[Graeme Gill]

yahvuu wrote:
> Chris Mohler schrieb:
>> I can express any CMYK color in RGB - but not the other way around.
>
> now i'm confused :)
>
> Is CMYK->RGB->CMYK roundtrip safe?

It depends on the gamuts of the respective colorspaces.
These are all device dependent colorspaces, so their
gamuts depend on the device in question. A gamut
can be described by a 3 Dimensional volume, and in
general two gamuts will have some region in common,
a region unique to one gamut, and
a different region unique to the other gamut.
This is often the case with RGB and CMYK
spaces (ie. sRGB and a typical offset press).

Whether CMYK->RGB->CMYK is roundtrip safe depends
on whether the RGB space fully encompasses the CMYK space,
or (if it does not), if the gamut mapping is being
reversed through the transformations.
Some people deliberately use a very large RGB gamut working
space to avoid clipping CMYK colors.

Note that by definition you loose the black inking information
though such a conversion, as well as a degree of fidelity.

A traditional graphic arts workflow often looks
something like:

   Capture in RGB

   Edit/adjust in RGB and/or Lab

   Convert/Separate to CMYK

   Adjust in CMYK

   Layout/Compose/Add non-image elements in CMYK.

   Convert to RGB for soft preview.

   Print the CMYK.

Although there are other more complicated ones,
including late binding (separating for the particular
output device after layout/composition).

Graeme Gill.



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

[Louis Desjardins-2]

Guillermo Espertino a écrit :

> Even though I agree that most of the CMYK cases mentioned use CMYK
> almost as spot colors, I can think of a very common usage scenario in
> Graphic Design where you need to be able to edit CMYK directly:
>
> Corporate colors.
> Most frequently Pantones. Brands have their corporate colors and ask
> designers to use them, but they can not always afford extra spot passes
> in offset press, so the colors have to be converted to the most
> aproximate CMYK combination (the Pantone Bridge catalog is for that).
>
> So you have to adjust the color of a photograph of a sign, a truck and a
> producto of your client to their corporate CMYK color.
>
> It's a photograph, you need CMYK, you can't use spot.
>
> This is a very common scenario, and it's a task for a image manipulation
> program.

I cannot agree more. It’s day-to-day work, day-to-day reality.

We could add dozens of examples, I guess.

To this point I don’t believe it’s that important to start figuring out
whether the case is as good an example as it possibly can. I guess we
are not at all trying to make the trial of the use of CMYK in the
printing industry! (Now, that would be a total waste of time!) For those
interested I bet a full glass of beer — available at LGM! — that they
can find without too much efforts plenty of explanations about CMYK use
in the printing industry on the web. Even non-offset printing go by CMYK
and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or
Vivid Magenta and some Black variations. Somehow, somewhere in the
process these printers need to convert the data so the printer can use
one of the CMYK inks that’s in the machine, be it toner or printing ink.
There is no way to ignore this reality.

We’re back to the basics of color reality. It’s either a projection of
light or a reflexion of light. I mean, there are good books on the
subject. This part is easy.

At this point in the discussion, it would be great to hear if the
quality of the information provided so far in terms of explanations and
examples is enough to lead someone or a group of developers in the GIMP
team to envision how this CMYK capability would be implemented into GIMP
and into what kind of developing frame (time, resource, GSoC, etc.)?

If we do need further examples, I am ready to provide more info,
although I find the examples so far to be really on target.

Cheers!

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

[Andrew A. Gill]

On Wed, 25 Mar 2009, Louis Desjardins wrote:

>
> To this point I don?t believe it?s that important to start figuring out
> whether the case is as good an example as it possibly can. I guess we
> are not at all trying to make the trial of the use of CMYK in the
> printing industry! (Now, that would be a total waste of time!) For those
> interested I bet a full glass of beer ? available at LGM! ? that they
> can find without too much efforts plenty of explanations about CMYK use
> in the printing industry on the web. Even non-offset printing go by CMYK
> and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or
> Vivid Magenta and some Black variations. Somehow, somewhere in the
> process these printers need to convert the data so the printer can use
> one of the CMYK inks that?s in the machine, be it toner or printing ink.
> There is no way to ignore this reality.

I am informed that some CcMmYK printers accept only RGB data.  In
such cases, it would be better not to convert to CMYK, since it
will only have to be converted back to RGB before it goes to the
device.

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

[Louis Desjardins-2]

Andrew A. Gill a écrit :

> On Wed, 25 Mar 2009, Louis Desjardins wrote:
>>
>> To this point I don?t believe it?s that important to start figuring out
>> whether the case is as good an example as it possibly can. I guess we
>> are not at all trying to make the trial of the use of CMYK in the
>> printing industry! (Now, that would be a total waste of time!) For those
>> interested I bet a full glass of beer ? available at LGM! ? that they
>> can find without too much efforts plenty of explanations about CMYK use
>> in the printing industry on the web. Even non-offset printing go by CMYK
>> and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or
>> Vivid Magenta and some Black variations. Somehow, somewhere in the
>> process these printers need to convert the data so the printer can use
>> one of the CMYK inks that?s in the machine, be it toner or printing ink.
>> There is no way to ignore this reality.
>
> I am informed that some CcMmYK printers accept only RGB data.  In such
> cases, it would be better not to convert to CMYK, since it will only
> have to be converted back to RGB before it goes to the device.

This mostly depends on the RIP that is attached to the printer but
really, this doesn’t prove the point of the need of CMYK editing ability
to be wrong, does it?

Louis

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

[Andrew A. Gill]

On Wed, 25 Mar 2009, Louis Desjardins wrote:
>
> This mostly depends on the RIP that is attached to the printer but really,
> this doesn?t prove the point of the need of CMYK editing ability to be wrong,
> does it?

On the contrary.

Just trying to give people all the facts.  I find it helps to
avoid being accused of partisanship.

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

[Louis Desjardins-2]

Andrew A. Gill a écrit :

> On Wed, 25 Mar 2009, Louis Desjardins wrote:
>>
>> This mostly depends on the RIP that is attached to the printer but
>> really, this doesn?t prove the point of the need of CMYK editing
>> ability to be wrong, does it?
>
> On the contrary.
>
> Just trying to give people all the facts.  I find it helps to avoid
> being accused of partisanship.

:-)

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

[Martin Nordholts-2]

Andrew A. Gill wrote:
> [from here out, `you' refers to core GIMP developers]
>
> We want you to succeed, and all you need to do to succeed is to
> address some of the issues that users need.  If you're telling us
> that GIMP has no intention of ever providing those things, we'll
> find another product.  Maybe Krita when it becomes vaguely
> stable, or maybe a fork.
>  

With all the excellent input from people in the printing industry,
including you, I think it is as clear as it can be. GIMP needs to
support editing in the CMYK color space. Support for editing only in the
RGB color space will simply not be enough. The details on _how_ to
support this is still an open question, but that we _need_ to is to me
just unquestionable.

> Here's a thought: I can code.  I'm sure others on this list can,
> too.  Why don't you tell us what you would require for a CMYK
> mode to be incorporated into the trunk of GIMP.  We can all read
> the API, but you can tell us what coding standards we need, what
> toes we can't step on and why other attempts to add similar
> functionality (like Cinepaint nee FilmGimp) foundered, and what
> we can do to avoid making those same mistakes.
>
> If you tell us what we need to do, we can do it.  That's the
> point of Open Source!
>
> If you don't, people are going to get sick of the excuses and
> simply move on to develop this functionality somewhere else.
>
> >From the outside, GIMP is seen as a shining example of what open
> source is capable of.  Inside the OSS movement, it's seen much
> like the XFree86 guys--constantly bickering about the same
> issues.  I'm sure that you'd have no trouble getting developers
> to work on a flagship product if they were convinced that it
> would end some of the internal conflicts in OSS.
>  

I must say I find this a bit arrogant. Supporting someone that is
inexperienced with hacking on the GIMP core to implement CMYK, which
arguably is the toughest task one can currently take on as far as GIMP
hacking goes, would be both very boring and very time consuming. That is
not something I want to spend my spare time on. If you want to help
implement better support for CMYK you should start working on and
looking into the GIMP code. After working on the code for a while you
will get your own ideas on how to implement CMYK in the best way.

I've been contributing code to GIMP for quite a while now, and I don't
know yet know exactly how to implement support for CMYK editing in the
best way. All I know is that GEGL will be a much better base for this
than the legacy code. So if you want to help getting CMYK into GIMP,
helping with the integration of GEGL will be a good start.

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

[Andrew A. Gill]

On Thu, 26 Mar 2009, Martin Nordholts wrote:
>
> I must say I find this a bit arrogant.

Maybe.  Probably.

But I think it's time for me a a user to stop telling developers
what I need and to start asking what you need to make that
happen.

I think it's time to stop looking at this from the position of
nebulous wants and desires and to start looking at the end
product and asking what restrictions need to be placed on its
development.  Where does it connect to the rest of the program?
How does it interact with the rest of the program?  When we know
that, we'll be able to start figuring out how best to implememt it.

> Supporting someone that is inexperienced with hacking on the GIMP core

I'm not asking for support.  I'm just asking you what the shape
of the hole is that the CMYK peg must fit into.

I'm not really suggesting that I tackle the problem, but in my
experience, the first response to ``You should have feature X''
is usually ``You forgot to attach the patch.''  Talk is cheap,
and somebody needs to offer to help.

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

[Andrew A. Gill]

On Wed, 25 Mar 2009, Vincent Lordier wrote:

> Hello happy CMYK warriors,
>
> This is valuable input you're giving actually
> How about collecting these use cases for prepress in the wiki here
> http://wiki.gimp.org/gimp/ ?

Well, I'm a man of my word and so I just contributed my wiki
attempt to do my part to change this from pie-in-the-sky
dreaming.

There's an incomplete draft here:

<http://wiki.gimp.org/gimp/ToDo/FloorpieCMYK>

I still need to come up with a good color correction example and
a good rich black example, but I should sleep now.

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

[Cédric Gémy]

> And finally, I agree with Sven that I don't know why anyone would
> want to have multipage PDF output for GIMP.

This is very simple : Illustrator CS4 has just implemented a real
multipage PDF support.
My opinion, if worth, is that gimp don't have to copy adobe software,
even if there are many good idea in those too. Gimp actual CMYK
conversion process is good for most of the jobs and actually much more
since i know only very few print shop working with a really accurate
Color management. But it's true and in some cases having too rich black
(such as 300 % or 360 % like i already get on day). Finally, there is a
plugin that can export each plate separately, but needs improvement too,
for sure. This is also the case with Inkscape. My workflow is usually to
make the PDF in Scribus after having imported the RGB picture. The
output seems to be better. (at least Adobe user could read InDesign
documentation and see this also the workflow recommended now even in
Adobe process. And i think once they'll have publish a complete PDF
Ripping process it will be more and more the case).

If that helps.

pygmee

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