GIMP PDF export plugin

[Jernej Simončič]

On Thursday, March 26, 2009, 21:20:53, Cédric Gémy wrote:

> This is very simple : Illustrator CS4 has just implemented a real
> multipage PDF support.

You mean something that CorelDraw had for years?

Then again, both CorelDraw and Illustrator are vector editing
programs, and having multiple pages in them is natual. GIMP OTOH is
primarily a bitmap editor, and as such multipage support doesn't make
much sense (and wouldn't easily fit in the workflow).

--
< Jernej Simončič ><><><><>< http://eternallybored.org/ >

Creativity varies inversely with the number of cooks involved with the broth.
       -- Fitz-Gibbon's Law

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

[yahvuu]

Hi all,

Louis Desjardins schrieb:

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

just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up):
I think this task can be done equally well in an RGB space, say sRGB.
If Pantone's Bridge has sRGB approximations, it should be trivial. If not,
you have to convert that single color from your best-guess CMYK to sRGB first.

Thanks to GEGL's dynamic nature, the sRGB->CMYK separation will be "live", so
the resulting CMYK can be cross-checked immediately, like read-after-write with
good old audio tapes.


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

Please do so. The general need for CMYK support beyond mere color separation
has been put out quite clearly. Yet AFAIKS none of the examples has shown a
requirement for doing actual image processing in CMYK space (which is
a good thing, btw). By this i mean anything which can't be done by processing
the "plates" as separate grayscale channels (see Øyvind Kolas's post).

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

[Guillermo Espertino]

El jue, 26-03-2009 a las 21:43 +0100, yahvuu escribió:
> Hi all,
> just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up):
> I think this task can be done equally well in an RGB space, say sRGB.
> If Pantone's Bridge has sRGB approximations, it should be trivial. If not,
> you have to convert that single color from your best-guess CMYK to sRGB first.

It won't be useful if the image has to be imported in a program that
actually lets you assign CMYK values.
Following with my example, the bitmap could be imported into scribus and
put together with a logo, with the right CMYK values.
Chances are that, though quite similar, the colors won't be the same.

> Thanks to GEGL's dynamic nature, the sRGB->CMYK separation will be "live", so
> the resulting CMYK can be cross-checked immediately, like read-after-write with
> good old audio tapes.

But it will still be difficult to specify a color. For instance: I need
the background of the image to be C=60%, K=100%.
I'd use that combination because I want a rich black with cold shades of
gray.
If I use RGB, the separation will include Magenta and Yellow depending
on the output profile and I wouldn't want that.

> Please do so. The general need for CMYK support beyond mere color separation
> has been put out quite clearly. Yet AFAIKS none of the examples has shown a
> requirement for doing actual image processing in CMYK space (which is
> a good thing, btw). By this i mean anything which can't be done by processing
> the "plates" as separate grayscale channels (see Øyvind Kolas's post).

It's fine to adjust the grayscale channels if we get a corrected preview
interactively. In fact, that's the way you do some adjustments in
Photoshop.
But there are several tools (channel mixer, curves) that is useful to
have working in CMYK space.

---

Also, in this discussion it seems that it was never considered that you
can be working on images that somebody else sent you and you don't
control how they were created.
If somebody sent you a separated tiff of a magazine ad and you have to
do some editing on it, you'll be destroying the original separation
converting it to RGB. And that's unacceptable.

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

[Alexandre Prokoudine]

2009/3/27 Guillermo Espertino wrote:

> Also, in this discussion it seems that it was never considered that you
> can be working on images that somebody else sent you and you don't
> control how they were created.
> If somebody sent you a separated tiff of a magazine ad and you have to
> do some editing on it, you'll be destroying the original separation
> converting it to RGB. And that's unacceptable.

It was actually covered by one of the examples I provided, where a
user had to do a poster in another application, because the main image
was saved and sent in CMYK by his customer :) While it's important to
teach customers not to @#$%$#% do so :), it's also important to teach
*and* still be able to do the job. Otherwise you would have no return
customers and that's what really matters.

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

[yahvuu]

Alexandre Prokoudine schrieb:

> 2009/3/27 Guillermo Espertino wrote:
>
>> Also, in this discussion it seems that it was never considered that you
>> can be working on images that somebody else sent you and you don't
>> control how they were created.
>> If somebody sent you a separated tiff of a magazine ad and you have to
>> do some editing on it, you'll be destroying the original separation
>> converting it to RGB. And that's unacceptable.
>
> It was actually covered by one of the examples I provided, where a
> user had to do a poster in another application, because the main image
> was saved and sent in CMYK by his customer :) While it's important to
> teach customers not to @#$%$#% do so :), it's also important to teach
> *and* still be able to do the job. Otherwise you would have no return
> customers and that's what really matters.

actually, it was your first item in the list ;)


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

[Andrew A. Gill]

On Thu, 26 Mar 2009, yahvuu wrote:
>
> just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up):

No, you're not.

That came out a little sharp.  Let me try to soften it.  You're
entitled to your opinion, but I just want to make sure that
there's no misunderstanding.

> I think this task can be done equally well in an RGB space, say sRGB.
> If Pantone's Bridge has sRGB approximations, it should be trivial. If not,
> you have to convert that single color from your best-guess CMYK to sRGB first.

I said before that I didn't think this was a real use for CMYK,
but that is because I think that even if GIMP had CMYK support,
it would not be able to perform this task well enough.  GIMP
would need native Pantone support, which I don't think is really
that useful at this time.

As little as I trust Pantone to CMYK, I trust Pantone to RGB
even less.

> By this i mean anything which can't be done by processing
> the "plates" as separate grayscale channels (see ?yvind Kolas's post).

This is not fun.  What you are suggesting is a very laborious
process, and having such a process work properly would probably
result in tens of minutes to hours of wasted time, depending on
the image in question.

And it still would result in one of the following:

1.) A helper application which creates the CMYK image
2.) GIMP still is unable to deal with trapping or rich black.

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

[Øyvind Kolås]

On Thu, Mar 26, 2009 at 10:14 PM, Andrew A. Gill
<superluser@...> wrote:

> As little as I trust Pantone to CMYK, I trust Pantone to RGB
> even less.
>
>> By this i mean anything which can't be done by processing
>> the "plates" as separate grayscale channels (see ?yvind Kolas's post).
>
> This is not fun.  What you are suggesting is a very laborious
> process, and having such a process work properly would probably
> result in tens of minutes to hours of wasted time, depending on
> the image in question.
>
> And it still would result in one of the following:
>
> 1.) A helper application which creates the CMYK image
> 2.) GIMP still is unable to deal with trapping or rich black.

I was not describing user interface anywhere in my mail, I was describing
underlying implementation mechanisms. GEGL stores pixels in buffers
that can store and on demand convert to and from RGB, YCbCr, CIE Lab
and Grayscale (dynamically extendable with other color models).
Allowing image processing operations to be implemented using the
models best fit for a particular operation.

GeglBuffers are not designed to deal with the special cases of multi
spectral images (lets say 32bands), spot colors (print plates). Render
layers as present in EXR files (blender for instance produces multiple
layers that are useful in post processing of the render). These will
have
to be dealt with on top.

For CMYK the following ops need to be implemented:

CMYK-from-RGB - takes a GeglBuffer as input, has options for black
subtraction, ICC profile selection, gamut handling and similar,
provides four gray scale GeglBuffers as output.

CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input
and provides an RGB soft proof.

CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl
actually support very naive CMYK buffers, these buffers are fragile
and
should probably only be used as a prestep to passing the buffer to a
TIFF or similar saving op.

Similar duotone-from-RGB and a configurable duotone-to-RGB or special
five channel ops for use with CMYK with additional spot colors, or
perhaps even a generic configurable ink-mixer op could be implemented.

If a person with interest in these things want to he could also add
support for 1bit GeglBuffers and generate the final raster to be
printed at the printers native DPI.

The primitives above should provide both preview and control over CMYK
the fact that the innermost core doesn't care about CMYK would
probably bleed into the user interface in the form that not all
operations operate on CMYK images like they do on RGB images, it might
not even make sense to accomodate for having layers of CMYK objects
but only cater to the hard-core CMYK needs of pre-press, with a core
set of the tools (color picker, color balance, curves, color picker)
aware of how to deal with the CMYK bundle. Doing things like blurs and
pastes would normally operate on the single selected plate, but
electing to process for all plates should be possible.

At the moment I do not have interest in CMYK but the above outline is
in line with my ideas on how GEGL should evolve.

/Øyvind K.
--
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Robert Krawitz-2]

   Date: Thu, 26 Mar 2009 23:08:37 +0000
   From: =?ISO-8859-1?B?2Hl2aW5kIEtvbOVz?= <islewind@...>

   For CMYK the following ops need to be implemented:

   CMYK-from-RGB - takes a GeglBuffer as input, has options for black
   subtraction, ICC profile selection, gamut handling and similar,
   provides four gray scale GeglBuffers as output.

   CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input
   and provides an RGB soft proof.

   CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl
   actually support very naive CMYK buffers, these buffers are fragile
   and
   should probably only be used as a prestep to passing the buffer to a
   TIFF or similar saving op.

   Similar duotone-from-RGB and a configurable duotone-to-RGB or special
   five channel ops for use with CMYK with additional spot colors, or
   perhaps even a generic configurable ink-mixer op could be implemented.

   If a person with interest in these things want to he could also add
   support for 1bit GeglBuffers and generate the final raster to be
   printed at the printers native DPI.

FYI, most inkjet printers these days are actually 2 bits per physical
channel.

A lot of this already exists in Gutenprint; you may want to look at
that.

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

[Andrew A. Gill]

On Thu, 26 Mar 2009, ?yvind Kol?s wrote:
>
> I was not describing user interface anywhere in my mail,

To be honest, I think I missed your message.

If I have mischaracterized what you have said (and judging from
what you say below, it looks like someone has), I crave pardon.

Here's what I was disagreeing with:

yahvuu:
> > > Yet AFAIKS none of the examples has shown a requirement for
> > > doing actual image processing in CMYK space (which is a
> > > good thing, btw).

To justify this, the message continues:

yahvuu:
> > > By this i mean anything which can't be done by processing
> > > the "plates" as separate grayscale channels (see ?yvind
> > > Kolas's post).

It sounds to me like the latter sentence is referring to the UI,
considering the content of the former sentence.

> I was describing
> underlying implementation mechanisms. GEGL stores pixels in buffers
> that can store and on demand convert to and from RGB, YCbCr, CIE Lab
> and Grayscale (dynamically extendable with other color models).
> Allowing image processing operations to be implemented using the
> models best fit for a particular operation.

I certainly don't take issue with that.

> At the moment I do not have interest in CMYK but the above outline is
> in line with my ideas on how GEGL should evolve.

At first blush, what you said seems about right.  I'll read it
more closely and give it more thought.

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

[yahvuu]

Hi all,

my previous posting does not stand a quality test, to put it mildly.
To save the list from multiple nearly indentical follow-ups,
i thinks it's best to bundle my replies here.
My apologies for the noise.


yahvuu schrieb:
> Thanks to GEGL's dynamic nature, the sRGB->CMYK separation will be "live", so
> the resulting CMYK can be cross-checked immediately, like read-after-write with
> good old audio tapes.

that's my personal wishful thinking. I have to take the blame for misguiding
user interface speculations.


> Yet AFAIKS none of the examples has shown a
> requirement for doing actual image processing in CMYK space

this is plain wrong. Already the levels & curves example shuts me up.


greetings,
peter

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

[Sven Neumann]

Hi,

On Wed, 2009-03-25 at 23:21 -0400, Louis Desjardins wrote:

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

Without CMYK support in GEGL/babl, there will be no direct editing of
CMYK in GIMP. So whoever wants to see CMYK editing in GIMP should help
to
 - change GIMP to do all editing using GEGL
 - make sure that babl/GEGL gains first-class CMYK support


Sven


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

[Graeme Gill]

Andrew A. Gill wrote:
> As little as I trust Pantone to CMYK, I trust Pantone to RGB
> even less.

Actually, Pantone to Spectral to L*a*b* to device space (RGB/CMYK whatever)
is pretty good.

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