[Scribus] CMYK: Last post on this topic - I promise ;)

[David Purton]

After this one, I'll drop my CMYK in Scribus posts. Everyone is probably
sick of me for sure by now.

I did a quick and dirty scan of a couple of pages from a Pantone Process 
Colour SWOP colour fan. It's pretty dodgy, but the colours are in the
right sort of area.

I've compared this with the proofs from CorelDRAW, little CMS via
tifficc, the eps imported (interpreted) into Scribus and a CMYK tif made
from the eps inserted as a graphic into Scribus.

Here if you want it:

  http://marshwiggle.net/pantone.eps
  http://marshwiggle.net/pantone.png

If this doesn't convince people that I have a point, then nothing will.


If it's my last post, at least let me make it a long one :) I have some
questions for Peter (though of course I would like to hear comments from
others as well), and some suggestions for things that could be
incorporated into Scribus to solve the issues that I raise.


I've been thinking about how Peter might have got such good results.
(BTW I don't doubt that you did - apologies if you might have thought
that my complaints somehow cast doubt on what you say).

So can you confirm or correct a couple of guesses for me?

Scribus does seem to have superb pdf support. When you've sent stuff to
print, did you use the PDF X-3 export? And then just send this to you
prepress bureau?

I don't know much about PDF X-3. We use very few bitmap images and work
exclusively in CMYK (using colours picked from experience or from pantone
colour fans) and then send straight DeviceCMYK colour space postscript
to our bureau. They then just produce film based on these. No colour
profiles are involved. Anyway that's an aside.

I gather that pdf x-3 pretty much tags every image and object with a
source colour profile. The pdf includes the your specified output
profile. Is this right?

The print bureau would then take this file - run it through their fancy
RIP which would do all the appropriate colour transforms, taking into
account their in house profile for their press and produce film that
when printed gives output closely resembling what you see on screen. How
am I doing so far?

Since there is really no app under linux that can produce CMYK tifs, I
would guess that all images you have used are RGB, either tagged with an
appropriate scanner/camera profile or assumed to be sRGB, right?

So when you make a pdf containing a bitmap, it would be still in RGB
with an attached RGB profile, right?

Now it's also possible to specify a profile for solid objects when
creating a pdf. Presumably you use sRGB again, yes?

So when solid objects are exported, they are exported as RGB based on
the RGB colours in the colour chooser and tagged with sRGB.
Still going ok?

It would follow therefore that the final separations would not be the
same as that of the CMYK colour chooser in Scribus, but rather the
numbers from the scribus RGB colour chooser munged through various
profiles, right?

If this is correct, then I can see that you would indeed get excellent
results with a good monitor profile.



I notice too, that it is possible to export the pdf without using
profiles for solid colours. In this case I am guessing from the pdf
created that the colours are exported as what is seen in the scribus
CMYK colour chooser, and tagged with (or assumed to be tagged with) the
output profile you have specified in creating the pdf.

If I want to specify and exact pantone colour using scribus, I guess
that I must do it this way, and put up with incorrect on screen colours.

This would be a wishlist bug for me. I would like to be able to specify
a colour as an exact CMYK pantone colour and have it soft proof
accordingly on screen.

The only way I can see this being possibly is if scribus adds a flag in
each colour, indicating if it is a CMYK colour (in the current output
profile) or an RGB colour (in the current RGB working profile). The
colour chooser could then be altered so that instead of just doing
unmanaged transforms from CMYK to RGB, when you changed type, little CMS
could be used to do the transforms based on the RGB working profile and
the currently selected output CMYK profile.

This would bring Scribus into line with other
prepress orientated applications that I have used.

Does this make sense?

Another issue with solid objects, related to the what scribus produces
when I print separations. Solid objects separate into the values
specified in the scribus CMYK colour chooser, *even* if I have elected
to apply icc profiles. This would seem to be at odds with what is
happening with the pdf export. To be consistent, Scribus should do a
managed colour transform before separating the objects when the user
elects to apply icc profiles.

What do you think?


Ok - that's solid objects, now for bitmaps in CMYK colourspace.

I'll just talk about untagged CMYK tifs, which I think Scribus should
assume are press ready and already in the colour space described by the
currently selected output profile.

As far as on screen display goes, I confess to not understand what
scribus is doing. All things been equal, I would have expected the on
screen display of colours in tifs to be the same as solid object
colours. See the last two columns in the png at the top of this email,
to see the difference.

Can you explain to me why they are different?

The Scribus on screen display of CMYK tifs is always the same as RGB
tifs. It looks like it does some kind of transform from CMYK to RGB,
then uses the currently selected image profile and output profile to
create a soft proof.

Again my wishlist would be for scribus to assume that an untagged CMYK
tif is press ready and soft proof it to give colours that are same as my
wish for solid colours talked about above. This again would bring
Scribus into line with other apps I have used.

Now it's hard for me to know exactly what scribus is putting into these
pdf X-3 documents, so for the moment I will talk only about the
separations that scribus gives when I print separations.

  a) Separations produced with "apply icc profiles not ticked":
       The output is based on the raw CMYK number in the file - fair
       enough.

   b) Separations produced with "apply icc profiles ticked":
        IMO, in this case, scribus should assume that the CMYK tif is
        already press ready and again spit out the raw numbers from the
        tif.
        What scribus actually appears to do is do an unmanaged transform
        from CMYK to RGB colour space and then use the currently
        selected bitmap colour profile to produce the separations.


So basically, you could sum up my wishes in this way:

I want to have distinct and separate treatment of both objects and
images depending on the colourspace they are specified in.

CMYK objects and images should be assumed to be press ready - what you
ask for is what you get in the separations. On screen display needs to
reflect this.

RGB objects and images should be treated as scribus currently does.


What are you thoughts?


Thanks for reading (if you get this far).

No need to hurry in giving answers, but I really would appreciate
hearing your thoughts.


cheers

dc

-- 
David Purton
dcpurton at chariot.net.au
 
For the eyes of the LORD range throughout the earth to
strengthen those whose hearts are fully committed to him.
                                 2 Chronicles 16:9a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: Digital signature
Url : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20041208/353b2043/attachment.pgp