[Scribus] cmyk workflow

jon info
Mon Feb 5 20:27:45 CET 2007


>>
> (...)
>>> Thus my workflow has been:
>>>
>>> 1. Import unedited image
>>> 2. Scale the image + its frame until it fits as I wish
>>> 3. Use Gimp to rescale my image to the size I found in 2)
>>> 4. Import the changed image
>>> (3 and 4 are meant to save space, I don't think you *have* to do  
>>> this)
>>>   And when I am totally finished
>>> 5) Export the whole document as pdf -- then the image should be
>>> converted to CMYK by Scribus, or so I thought it was at least ...
>>>
>>> But I have a problem concerning this:
>>> Right now I got a telephone from my printer saying my pdf resulting
>>> from
>>> these steps are not usable, but greyish instead of grasgreen.
>>>
>>> See the results yourselves here:
>>> http://www.bojer.no/Ariadne2006/ariadnes_aarbok2006-omslag-
>>> ForSkjerm.pdf
>>> http://www.bojer.no/Ariadne2006/ariadnes_aarbok2006-omslag-
>>> TilTrykking.pdf
>>>
>>> ("skjerm" means screen, and is the rgb variant, "Trykk" means print  
>>> and
>>> is the one intended to be printed).
>>>
>>> When I look at it in XPD or Kpdf it really looks greyish, as he said
>>> (he used Windows I suppose, at least he said he was using Acrobat),  
>>> but on
>>> acrobat on Linux it show as it should, no greyish tone to it as in
>>> xpdf.
>>>   Having repeadedly read in thes thread, that acrobat is to be  
>>> trusted
>>> over all the other pdf-programs, I trusted it to be OK, but it seems
>>> not. Or is he mistaken??
>>>
>>> Now, what I have as a pdf-file is made out of many imageframes  
>>> linking
>>> to the same picture. This gives a nice effect, and keeps the file
>>> pretty
>>> small. But the printer was in doubt wether his equipment would be  
>>> able
>>> to use it, I am not sure, but said I think it ought to be ok (after  
>>> all
>>> this function is quite the same as in other DTP programs, so I  
>>> excpect
>>> this to be no different). But he wanted me to ?flatten the image?,  
>>> that
>>> is merge all my layers into one.
>>
>> Flatten  here should mean reduce transparencies to real.
>> As your file looks - you are using transparancies wich are not
>> printable as long as
>> your printer doesn't use sufficient equipment or ripping procedures.
>> Unauthorized rendering of transparencies sometimes leads to unwanted
>> results.
>
> Yes, i sorted that thing out :-)
> The strange thing though is, is that also when all the file is just one
> single rgb tiff file I get the same issue (grayish in kpdf and xpdf,  
> but
> not in acroread). Could someone on wondows (or mac perhaps) please take
> a look at
> http://www.bojer.no/Ariadne2006/ariadnes_aarbok2006-omslag- 
> TilTrykking-BareEttBilde.pdf
> and see if it show up grayish? And then what about
> http://www.bojer.no/Ariadne2006/ariadnes_aarbok2006-omslag- 
> TilTrykking.pdf
> The latter is the one with all the layers and the transparency.
> By me they show up just the same. So how am I supposed to know if the
> printer can use them or not? (OK, I know, I should be carefull with
> transparency, but apart from that, I mean ...)

Ok. If you use transparencies and your printer cannot handle it - you  
will get your frontmost plants black in white box.
The plants in the background will have some sort of grid lines and  
their boxes will overlay but not overprint.
Something like that, depending on the rendering engine.
This said ...

> For reference, here is the image file:
> http://www.bojer.no/Ariadne2006/ariadnes_aarbok2006-omslag- 
> somBildeGB.tiff

I see - the tiff is an output from scribus?
You can see what applications do when they are not capable of  
transparency conversion? :-)
Something strange happend here also, or did you change the colors of  
some of your typo to hmm.. blue instead of light yellow?

>>> So the only reasonable way I found
>>> (without having to redo everything) was to export as png, put this  
>>> png
>>> file as the only element in a new file with the same dimensions and
>>> then export to pdf again.
>>> I looked at the png-file in Gimp, and it looks ok and is RGB.
>>> The resulting file though is really greyish. Now I am not quite sure
>>> how
>>> to solve this, I had trusted Scribus to just solve this for me by
>>> export time ...
>>
>> You might trust scribus only if you know what you are doing. RGB to
>> CMYK conversion is not a simple thing.
>> The color space of RGB is much wider than CMYK. Colors displayable in
>> RGB are not always convertable to CMYK.
>> e.g. rgb (0,100,0) is by no way reproducable in cmyk it might be
>> clipped to, say, cmyk (50-0-100-0).
>> Everything here depends on colormanagment modules, rendering intents
>> and profile settings.
> (...)
> I  will take a look at your suggestions, especially if someone can tell
> me if the last file is not ok :-/

No the file is not ok, sorry.

For this time and if you are in a hurry, you might send me a pdf (pdf  
X-3) with your rgb
pictures and transparencies and embedded fonts in it and I will try to  
convert it to something
more usable , though I am not sure that the results will suffice.

>> Another way around is to change the colors in your png (in Gimp) to
>> something which in your opinion
>> might be printable. And reimport these files.
>
> Yes, but grasgreen is almost the only colour (along with some tones of
> yellow), is that a colour especially tricky to convert from rgb to  
> cmyk?

With CM on you can turn on gammut warning in scribus (with scribus  
1.3.3.7 on OS X 10.3
it seems broken, but I am still not really sure if I understand how it  
is intended to work)

With gammut warning on you should be able to see wich colors will be  
clipped.

All "clean" rgb colors are not reproducable in cmyk or at least not  
printable.
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : Bild 2.jpg
Dateityp    : image/jpeg
Dateigr??e  : 5411 bytes
Beschreibung: nicht verf?gbar
URL         : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20070205/66e9fbab/attachment-0002.jpg 
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde abgetrennt...
Dateiname   : Bild 3.jpg
Dateityp    : image/jpeg
Dateigr??e  : 7663 bytes
Beschreibung: nicht verf?gbar
URL         : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20070205/66e9fbab/attachment-0003.jpg 
-------------- n?chster Teil --------------


Above a sample of "generic" 2 dimensional color (omitting luminance) 
spaces belonging to 1. cmyk and 2. rgb
If you convert rgb to cmyk these spaces got to be mapped.
Jon



>
> Best regards
> Axel Bojer
> _______________________________________________
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus
>



More information about the scribus mailing list