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
