GIMP PDF export plugin

[Graeme Gill]

Sven Neumann wrote:
> 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.

It really depends on what you are used to. To *you* RGB seems natural,
while to someone who has been brought up in the printing world, CMYK
seems natural, and it's RGB that is "weird". (You know which
is which when you ask them to evaluate a photograph. If they
say things like "it needs a couple of percent more magenta
in the mid tones, and a little less yellow there, ...", they
are from the print world, and think in CMYK. Many of these
professionals are unbelievably good at being able to spot what
needs to be done to an image in CMYK to correct it).

When preparing photographs for printing, it is extremely common
to want to edit them in CMYK space so as to be able to get the
best looking result within the limitations of that colorspace,
and to meet other technical requirements (total ink coverage,
black separation, etc.).

There is also the question of whether you define your goals
narrowly as photographs, or more generally as images or raster files.
If the latter, then there (ideally) shouldn't be any limitation
on the number of channels or colorspaces supported by an editing program.

Graeme Gill.

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

[Robert Krawitz-2]

   From: Guillermo Espertino <gespertino@...>
   Date: Mon, 23 Mar 2009 19:59:53 -0300

   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.

Or dirty green/cyan, or dirty magenta, depending upon the colorants...

   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.

This really sounds like you're using black as a spot color rather than
going generic editing in CMYK space.

I question whether doing this in an image editing application is
really the right thing to do.  If you're doing black text, you
probably want the text to be vector rather than raster anyway --
printing an image scaled to 240 DPI is fine, but the text won't look
so good at that resolution.  In that case, you're better off using
something like Scribus to do that kind of overlay, at least until GIMP
has vector layers.

   Well, I can't do duotones with Gimp to insert in a 2 inks flyer.

Which again is a spot color kind of use case rather than a CMYK use
case.

   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.

Does that indicate that separate+ is what needs to be enhanced, rather
than the core application?

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

[Guillermo Espertino]

Hi Robert, thanks for your comments.

> This really sounds like you're using black as a spot color rather than
> going generic editing in CMYK space.

That was just an example. Another example could be just putting an image
in front of a gray gradient background.
In my experience, it's not that easy to find a printer that can convert
a RGB gray into a perfectly CMYK neutral grey.
Or isolating a photograph, putting it on a solid color layer and apply a
drop shadow of the isolated image on the color.
Why should I send an RGB file and see how my printer's RIP separates the
grays and the shadows when I could be specifying: I just want 100% black
over the color?
They are only real world examples. Probably there are excellent print
shops in Germany or USA that deliver excellent results from an RGB jpeg,
but that's not always the case.

> I question whether doing this in an image editing application is
> really the right thing to do.  If you're doing black text, you
> probably want the text to be vector rather than raster anyway --
> printing an image scaled to 240 DPI is fine, but the text won't look
> so good at that resolution.  In that case, you're better off using
> something like Scribus to do that kind of overlay, at least until GIMP
> has vector layers.

Again, that was just an example. It may be true in a brochure or a
magazine page, but what if you need to add a texture to a title,
breaking the borders of the characters with a "grunge" brush? or
something like that?

But let me show you a very simple example:
http://www.flickr.com/photos/superdd/2781429410/
This image was created in Inkscape and exported as PNG. Then in Gimp the
yellow part got some texture and color work.

What if I want to put that image in a page of a magazine that I'm
creating in Scribus, and I want the black part of the image to be the
same black (100% black) than the text.
In that case I would have, according to your workflow, to:
-take the image to gimp, make the texture part, remove the black part,
save it, import in scribus the color blob and a black-only SVG version
of the drawing, make them match in size and alignment (ouch, I should
have imagined that I would need some bleed on the color shape to avoid
alignment errors), and export them as a CMYK PDF to send to the print
shop

Or simply separate in GIMP to CMYK, remove the black part of the CMY
channels and tweak the black channel, save as TIFF and import in
Scribus.

Call me crazy but I choose the last one.

Of course there are alternative ways, but sometimes it's faster and more
direct, thus preferable, to do it with the image manipulation program
that using three or four separated applications for a simple task.


> Which again is a spot color kind of use case rather than a CMYK use
> case.

Yes, but we don't have spot channels either. At least having CMYK would
work as a viable temporal solution until we have spot channels.
I find it hard to imagine that GIMP will support spot channels if it
won't support CMYK channels. It wouldn't make much sense to add a spot
channel to an RGB image, would it?

> Does that indicate that separate+ is what needs to be enhanced, rather
> than the core application?

This discussion was about a PDF export plugin at the beginning.
I was trying to make evident that a PDF export plugin is probably
useless without CMYK/SPOT/VECTOR LAYERS, and improving and integrating
the Separate+ Plugin instead of focusing on a PDF exporter would make
sense and a big difference.

Gez

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

[Andrew A. Gill]

On Mon, 23 Mar 2009, Sven Neumann wrote:

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

Oh, sure.

Like I said, I mainly work with vectors and spot jobs, but I
have, in the past, had to deal with some of these issues.  Take
the following image, for example:

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

To properly print this image, it should be trapped--that is,
either the red plate or the black plate should be altered so that
the red and black overlap.  That way, a slight misregistration
won't result in a white gap along the border.  Trapping is
usually pretty small, around .25 pt, but here's an exaggerated
example of what will happen if you don't trap and the plates are
misregistered:

<http://i158.photobucket.com/albums/t102/superluser/whywetrap.png>

Some trapping can be done in vector programs and page layout
programs, but images with non-geometric edges like the one above
cannot.  I would have to do it in GIMP, but I cannot do it in
GIMP, because that would require having some of the pixels at
100% red and whatever shade of black it is at that point, and
GIMP cannot do that because it does not have CMYK support.

Likewise rich black.  In cases where you are printing black on a
multicolored border, it's useful to print in rich black, usually
60%C, 100%K.  This makes the effects of trapping less noticeable.

You can find an example of rich black here:

<http://www.graphic-design-employment.com/over-printing.html>

Again, it is not possible to do this in GIMP without CMYK
support.

Also, color correction.  If I print a proof and it turns out that
it is too cyan, I cannot simply turn up the red, because that
will also adversely affect both the cyan and magenta plates.

And finally, I agree with Sven that I don't know why anyone would
want to have multipage PDF output for GIMP.  I'd much rather see
built-in DjVu support.

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

[jEsuSdA 8)-2]

El Martes, 24 de Marzo de 2009 03:03:36 Guillermo Espertino escribió:

>
> > Does that indicate that separate+ is what needs to be enhanced, rather
> > than the core application?
>
> This discussion was about a PDF export plugin at the beginning.
> I was trying to make evident that a PDF export plugin is probably
> useless without CMYK/SPOT/VECTOR LAYERS, and improving and integrating
> the Separate+ Plugin instead of focusing on a PDF exporter would make
> sense and a big difference.
>

I totally agree with Gez.
a PDF export plugin now as if you uses convert image.jpg image.pdf from imagemagick

Its more usable to improve separate first and later, when CMYK/SPOT/VECTOR LAYERS where integrated on Gimp, make a
complete pdf export plugin.


Salu2 de jEsuSdA 8)
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

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

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

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.

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

[Vincent Lordier]

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

(like the UI team did with brainstorm here : http://gimp-brainstorm.blogspot.com/ )

You could put it using these kind of chapters :
https://wiki.ubuntu.com/UbuntuWithoutRestricted

This way, we could specify the GIMP a bit better and coordinate dev efforts ;)

enjoy this day !

vincent

On Wed, Mar 25, 2009 at 16:21, Alexandre Prokoudine <alexandre.prokoudine@...> wrote:

On Mon, Mar 23, 2009 at 11:17 PM, Sven Neumann wrote:
> 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.

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.

Alexandre

_______________________________________________
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

[Alexandre Prokoudine]

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.

Alexandre
_______________________________________________
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:
>
> 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.

The Christian Science Monitor does this pretty frequently, and
2-color ads and brochures are fairly popular because they are
cheap.  You can look online for examples, but I have to get to my
prepress job now.

> To me it's somewhat strange that GIMP's product vision doesn't mention
> prepress needs explicitly.

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.

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

>
> 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/ ?
>
> (like the UI team did with brainstorm here :
> http://gimp-brainstorm.blogspot.com/ )
>
> You could put it using these kind of chapters :
> https://wiki.ubuntu.com/UbuntuWithoutRestricted
>
> This way, we could specify the GIMP a bit better and coordinate dev efforts
> ;)
>
> enjoy this day !

I'd be happy to, but I've got to get to work.  InDesign is a
flaky POS software that makes me wish there were a better free
alternative.

But since there isn't, I'll have to write up some examples when I
get 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

[Alexandre Prokoudine]

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

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

[peter sikking]

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.

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

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

[Alexandre Prokoudine]

On Wed, Mar 25, 2009 at 8:44 PM, peter sikking wrote:

> There is choice in there, and the user community cannot demand
> that GIMP does certain things.

It's quite an interesting point, because you are talking about
demanding, whereas I'm talking about meeting users needs :) And you do
understand the difference, do you? :)

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

So what you are saying basically is that you see GIMP users as human
beings living in a parallel world where all of the things mentioned
above do not exist, workflows are perfectly RGB based and nobody ever
has to deal with color separations other than exporting :)

Which means in fact that the team does not wish to meet *real*
prepress users needs on product vision level.

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

[peter sikking]

Alexandre Prokoudine wrote:

> On Wed, Mar 25, 2009 at 8:44 PM, peter sikking wrote:
>> There is choice in there, and the user community cannot demand
>> that GIMP does certain things.
>
> It's quite an interesting point, because you are talking about
> demanding, whereas I'm talking about meeting users needs :) And you do
> understand the difference, do you? :)

in general: users have lots of needs, but it is GIMP's team
choice to meeting these needs _well_. the stress is on well,
because if you decide to do it in your vision, you have to strive
to be the best in that department.

website mock-ups and code generation; multi-page, multi-column
page layouts; hard disk de-fragmentation: users have these
needs, but GIMP will not help them with these.

>> 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.
>
> So what you are saying basically is that you see GIMP users as human
> beings living in a parallel world where all of the things mentioned
> above do not exist, workflows are perfectly RGB based and nobody ever
> has to deal with color separations other than exporting :)

If you had carefully read what I am offering to design for
GIMP you will see that it is a lot more than an export.

I am talking about covering the main image window with a
"projection screen" in this case for cmyk, whenever one wants,
from the first to the last second of the project, that with
the profile
of the printing press will give you some idea (I know there are
limits) of how it will come off the press. this projection screen
will have its own layers where one can take corrective measures
to make the output look good within the possible output range.
these corrective layers will hen be used of course for the
mastering/export to cmyk. all the cmyk tricks you talk about
(ink decomposition, trapping) can be set up for the
projection screen and where possible previewed there.

the overall task is actually mastering the image for printing press,
where cmyk happens to be an important factor in the world of today.

> Which means in fact that the team does not wish to meet *real*
> prepress users needs on product vision level.


I would like to have this answered answer first: why can't they
do it with scribus? are we the last piece of (free) software
in the world that can help them?

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

[Chris Mohler]

On Wed, Mar 25, 2009 at 12:44 PM, peter sikking <peter@...> wrote:
> Mix master tape (in rgb) and then cut
> the lp (in cmyk).

I can express any CMYK color in RGB - but not the other way around.
Therefore, I "master" all of my print jobs in CMYK, and if I "cut"
something like a preview for a client then I use RGB space.  So you
see, it's actually quite the opposite in my world.  This is why GIMP
is only a small portion of my day to day work flow - it is not
printer-friendly (yes, friendly to the device sitting on your desk,
but not a person who is a printer).

And I agree that Scribus is coming along nicely and will (hopefully)
become a robust page layout program - but I think where GIMP comes
into the arena is creating a single image that will be printed (in a
magazine, screen printed, newspaper, whatever).  Something like
PDF+CMYK export is a good first step, but ultimately CMYK editing and
channel operations are needed to make GIMP suitable for preparing an
image for print.

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

[Chris Mohler]

On Wed, Mar 25, 2009 at 1:58 PM, peter sikking <peter@...> wrote:
> Alexandre Prokoudine wrote:

>> Which means in fact that the team does not wish to meet *real*
>> prepress users needs on product vision level.
>
>
> I would like to have this answered answer first: why can't they
> do it with scribus? are we the last piece of (free) software
> in the world that can help them?

Ah, but Scribus is a layout program, not an image editor.  Ideally,
one would prepare images for printing with GIMP, then embed them in a
page with Scribus.  Having control over the CMYK (or spot color)
makeup of the image in GIMP should make things smoother when setting
the image in Scribus.

As to the projection screen, that approach sounds complicated.  But if
it can give a fairly honest CMYK projection and allow for manually
adjusting the channels, then it would go a long way toward solving
some of these problems.

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

[Øyvind Kolås]

On Wed, Mar 25, 2009 at 7:06 PM, Chris Mohler <cr33dog@...> wrote:

> On Wed, Mar 25, 2009 at 12:44 PM, peter sikking <peter@...> wrote:
>> Mix master tape (in rgb) and then cut
>> the lp (in cmyk).
>
> I can express any CMYK color in RGB - but not the other way around.
> Therefore, I "master" all of my print jobs in CMYK, and if I "cut"
> something like a preview for a client then I use RGB space.  So you
> see, it's actually quite the opposite in my world.  This is why GIMP
> is only a small portion of my day to day work flow - it is not
> printer-friendly (yes, friendly to the device sitting on your desk,
> but not a person who is a printer).
>
> And I agree that Scribus is coming along nicely and will (hopefully)
> become a robust page layout program - but I think where GIMP comes
> into the arena is creating a single image that will be printed (in a
> magazine, screen printed, newspaper, whatever).  Something like
> PDF+CMYK export is a good first step, but ultimately CMYK editing and
> channel operations are needed to make GIMP suitable for preparing an
> image for print.

I consider spot colors much more important than CMYK. I also consider CMYK
a special case of spot colors. Spot colors could be implemented using GEGL ops
that take a set of grayscale buffers (plates) as input and provides
RGB soft-proofing
(potentially even animated for gloss/metallic inks). This would leave
the image processing
algorithms dealing with sane or mildly sane color models like gray
scale, RGB, YCbCr or CIE Lab,
while allowing the user direct control over the contents of spot
colors and seeing a preview
of the resulting processing.

If the above is considered CMYK support I would be supportive of it.
CMYK support in the
form of CMYK and CMYKA pixel buffers as a first class citizen (or even
a third grade citizen)
with support in most operations and routines is something I will
continue to oppose.

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

[Alexandre Prokoudine]

On Wed, Mar 25, 2009 at 9:58 PM, peter sikking wrote:

> If you had carefully read what I am offering to design for
> GIMP you will see that it is a lot more than an export.
>
> I am talking about covering the main image window with a
> "projection screen" in this case for cmyk, whenever one wants,
> from the first to the last second of the project, that with
> the profile
> of the printing press will give you some idea (I know there are
> limits) of how it will come off the press. this projection screen
> will have its own layers where one can take corrective measures
> to make the output look good within the possible output range.
> these corrective layers will hen be used of course for the
> mastering/export to cmyk. all the cmyk tricks you talk about
> (ink decomposition, trapping) can be set up for the
> projection screen and where possible previewed there.

So at the point of final projection users will gain access to each of
the CMYK channels separately? That indeed sounds like a fair solution.

However, there still is a question of being able to use spot colors,
e.g. in vector layers.

> I would like to have this answered answer first: why can't they
> do it with scribus? are we the last piece of (free) software
> in the world that can help them?

You can do things like using spot color based duo-/tri-/quadrotones in
Scribus, but you run into limitations, because these kinds of raster
effects are not a natural part of a desktop publishing application.
And a DTP application tends to rather collect and layout already
mastered content than try to substitute a sophisticated vector or
bitmap graphics editor.

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

[yahvuu]

Hi,

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?
>From past examples (trapping, rich black) i've come to think that
hand-optimized CMYK separations can't be transformed back
to RGB losslessly (quite opposite to gamut issues).
Can some RGB color space be tricked to accommodate overprinting uses?

greetings,
peter

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

[Chris Mohler]

On Wed, Mar 25, 2009 at 2:44 PM, yahvuu <yahvuu@...> wrote:
> Hi,
>
> 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?

Not really.  What I was trying to say is that I send RGB proof images
to my customers, even though the artwork is in CMYK - and they get a
fairly honest representation of the final print.  I do not actually
convert from CMYK->RGB->CMYK  though - just export RGB from the CMYK
image.

> >From past examples (trapping, rich black) i've come to think that
> hand-optimized CMYK separations can't be transformed back
> to RGB losslessly (quite opposite to gamut issues).

Yeah - that will lead to problems.

> Can some RGB color space be tricked to accommodate overprinting uses?

On that I have no idea...

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