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

[Craig Ringer]

On Wed, 2004-12-08 at 22:02, David Purton wrote:
> After this one, I'll drop my CMYK in Scribus posts. Everyone is probably
> sick of me for sure by now.

Hardly. I work in prepress myself, but our printers currently take
untagged PDFs and we do our CMYK conversion in Photoshop before
embedding files in Quark, so I don't know much about colour management
workflow.

I haven't yet examined colour-related issues about integrating Scribus
into our workflow, as there are many other things higher on my list.
Consequently, personally I don't know much about the situation. I've
been reading with interest, but unable to usefully contribute.

[snip PDF/X3 discussion I lack knowledge of]
>
> 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.

Indeed. A big wishlist for many is "real" Pantone spot support, but I
think there are licensing challenges to be overcome about that.

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

If I understand and recall correctly - and I'm hardly an expert on this
- 1.3 is going to be seeing significant changes in the way it stores and
manages colours. I don't know if this will be part of it, but if not
it's certainly the right time to think about it.

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

Makes sense to me, but see "hardly an expert" above.

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

While it might be worth having the /option/ to say 'Apply <profile> to
untagged CMYK TIFFs', I agree that the option of leaving them untouched
is important and probably a sensible default. Ditto CMYK EPS IMO.

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

Given that the only DTP app I've made significant serious use out of
will blink and say "what? huh?" in response to any talk of profiles, and
would be utterly incapable of anything approaching a soft proof, I'm
powerless to speak on this.

As Craig Bradney noted, those who really know what's going on here
(colour details and code details) are very busy currently, so it could
be a while. Nonetheless, I for one am interested in this. I think colour
management workflow is darn hard to understand and get right, so it's
important to carefully examine any possible issues. My own opinion only,
of course.

--
Craig Ringer