10 Pre-Press Tips For Perfect Print Publishing

[prepression]

Is anyone sold on the “Use RGB instead of CMYK”?

10 Pre-Press Tips For Perfect Print Publishing - Smashing Magazine

I am not sure who wrote this but I would be skeptical. Here's a link to an article that provides better prepress tips:

exploring digital prepress

[mattbeals]

Reid Anderson if I recall correctly. It's a good book.

[Lukas Engqvist]

Prepression I am not sure I agree with you. The simple reason is that separation RGB data and CMYK data is a very convenient way to handle colour management and safe CMYK at the same time. All RGB is colour managed and all CMYK is safe.
To some extent device links and inksave servers can fix problems that should not have occured with a workflow that follows best practices. I find them techniques to treat a symptom. I would still argue for a best practice and a workflow that is not dependant on "my configuration" (I have press repurposing, but I find that a little off the point).
Resizing all in Photoshop is not a practical solution, yes there are scripts and pluggins that will do it, but if you have an undecisive designer you may end up rescalling an image multiple times, wich is a greater evil than resizing in InDesign.
The phrase RGB colours cannot be matched in print is missleading, because with ECI RGB and coated paper most colours are matchable, most natural colours occuring in photographic images that is.

[pcmodem]

I used to be a firm believer in having the customer supply CMYK images each and every time. I am starting to believe in keeping the images as RGB and having them converted to CMYK when Exporting to PDF out of InDesign. It has taken me years to accept that RGB is better, in fact my final acceptance of it happened just last week. I don't practice an RGB workflow but that is the next step.

I do find it interesting in the link prepression posted. The Blog talks about only using CMYK, and then later talks about color managing your documents. If you don't have RGB images, why even color manage your document (unless you don't have a RIP to handle plate curves). He also says to use TIFF and EPS images and not native Photoshop (PSD) or Illustrator (AI) files. This writer is certainly in the 90's using a modern application. It is time he gets with the present day!

[Stephen Marsh]

I have seen similar actions, but find them hard to explain and even harder to teach to implement than an RGB workflow. I'd be interested to hear how the discussion went, from the link it provides an answer to an unasked question.

Hi Lukas, I try to get around a bit, however I have not seen such an action before. Have you any links for such similar actions?

I can't remember the original thread 100%, I think it was someone wanting an easy way to evaluate TAC in Photoshop, without having to do so in other software and without having to mouse around the image in Photoshop.

The problem is how do you handle the areas with too much colour? There is no action in photoshop to reduce ink or apply GCR or UCR on a selection, thought that would be necessary for these actions to be truly useful.

It is true that Photoshop does not have a purpose built function to play with GCR/UCR or reduce ink limits in an existing file. That being said, there are many tools, methods and techniques that one can use to reduce the total ink limit and shadow build with Photoshop. The folk that need to come up with these less than ideal hacks may not have access to DLP or other methods of ink saving and they may not wish to totally reseparate the entire image when it is only the total ink that needs minor adjustments.

Anyway, I may be barking up the wrong tree here on this forum, one time I remember running into Chicken Little at the Adobe forums, telling me that the sky would fall in if I adjusted the total ink or the GCR in a file using Photoshop...when from experience of ink on paper I knew otherwise. I did not wish to get into a pissing contest with someone that made many absolute statements without knowing the details on how I was adjusting the total ink build or GCR.


Regards,

Stephen Marsh

[Stephen Marsh]

This is not a problem for us who are using ink-optimizing software like: Binuscan CMS server, Gmg ink optimizer or cmyk2cmyk device link conversion. Dont see the need for this in Indesign. We never have to bother our customers with any TAC/TIC-issues.

Magnus, for those of us working in smaller shops that may not have such toys - could you provide a sample CMYK image, both before reducing TAC and after reducing TAC? I can supply an image if you can't. This would be much appreciated as an educational exercise.


Sincerely,

Stephen Marsh

[prepression]

Prepression I am not sure I agree with you. The simple reason is that separation RGB data and CMYK data is a very convenient way to handle colour management and safe CMYK at the same time. All RGB is colour managed and all CMYK is safe.
To some extent device links and inksave servers can fix problems that should not have occured with a workflow that follows best practices. I find them techniques to treat a symptom. I would still argue for a best practice and a workflow that is not dependant on "my configuration" (I have press repurposing, but I find that a little off the point).
Resizing all in Photoshop is not a practical solution, yes there are scripts and pluggins that will do it, but if you have an undecisive designer you may end up rescalling an image multiple times, wich is a greater evil than resizing in InDesign.
The phrase RGB colours cannot be matched in print is missleading, because with ECI RGB and coated paper most colours are matchable, most natural colours occuring in photographic images that is.

I prefer to convert images to CMYK so I can apply the right color profile to them. You can resize an image down, but not enlarge it without loosing image quality. Perhaps I am a purist, but I find the tried and true methods continue to produce better results.

[Tech]

Have anyone tried actually comparing final product results between RGB workflow vs CMYK workflow? Ultimately that should be the focus. If we all hit the bookstores and compare books printed in the 90s with CMYK workflow and compare to books printed in current flavor of RGB workflow, does anyone think there would be much if any visual difference??? Would end-user consumers that buy these print products care?

It's like arguing about old LCD vs new OLED display technology, each has it's flaws. Truth be told, only geeks like us would care which is what or how it's created, end-user/consumers just want quality products in their hands.

I'm not a firm believe in following any guidelines to the letter, I prefer taking what works and make sure it's efficient enough for everyone involved to follow without overkill and restrict creative solutions. If I have to keep a mix of RGB/CMYK workflow then so be it. Another truth be told, there are plenty of legacy Quark/CMYK files around to last us another decades or more. Who (some of you have) is going to throw money down a rabbit hole and convert to RGB workflow strictly? Who is willing to bet the next revolutionary printing technology is just around the corner and we'll all be arguing about a new workflow in another 5-10yrs? It can't be this much fun chasing your tails all the time can it? What are we? Cats, dogs or men? I say make the tools work for you, not the other way around!

[pcmodem]

I believe Tech has it right. In the end you want the tools to work for you.

13 years ago when I started in Prepress, we would change the Faux Bold and Faux Italic to the real font. This was time consuming but it made sure the file was right, I did it because it was the way I was taught. A year or so later after doing it this way and dealing with type re-flow, I asked why we changed the font mappings. It was because of an old RIP we didn't have any more, so I stopped making the changes. Jobs went through faster and the re-flow went away.

The whole point is, we can produce the same if not better results by leaving things alone and letting the system work for us, instead of us working for the system. Leave the RGB images alone, let the profiles convert the RGB images to CMYK. It will save you time.

[Magnus]

Magnus, for those of us working in smaller shops that may not have such toys - could you provide a sample CMYK image, both before reducing TAC and after reducing TAC? I can supply an image if you can't. This would be much appreciated as an educational exercise.
Sincerely,

Stephen Marsh

Here's a sample-image I just processed (before and after) with Binuscan CMS Server: http://www.magnussandstrom.se/download/ink_opt.zip
Theres a setting to adjust the "aggressiveness" but this sample is processed with a default setting. In this case the input and output profiles are the same, but in production we use Fogra39 as input and different "pressprofiles" as output and that is when you really gets the most out of it.

One of the pros. with this kind of software is that you dont need to set an TIC-limit. And you can get higher TIC in a (for instance) dark green color (see the square in upper left corner) then in a neutral black. This is not possible with any conventional converting methods (ICC/GCR/Device link etc) so far as I know..

Hope this works as an educational exercise Stephen!

And pcmodem, I second that! ^