10 Pre-Press Tips For Perfect Print Publishing

[kasperheim]

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

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

[ksherrod]

Never heard of that...not sure if I buy into it. I think you should create your art for your intended output format for the most reproducible color. Maybe you can't get the same range out of CMYK, but customers that create their files in CMYK are not as likely to see as significant of a difference between their screen and the printed piece. That article should be titled "Ten ways to add prepress charges to your next print order by creating your files incorrectly".

[William Campbell]

The article is misleading, and fuel for screw-ups when interpreted by the lesser-educated who are most likely to embrace the wonderful "advice."

Sure, we could argue that keeping data in RGB is keeping more of the data. Good for re-purposing. That's fine, but come print time, automatic conversions are no match for the hand of a craftsman, even given today's level of color management technology. And besides (considering re-purposing), shouldn't an image match across media? A screen can match the smaller CMYK gamut easily. A press will never match a vivid RGB image. Why not choose the lowest common denominator? Get to a perfect CMYK image, and instead of as the author suggests, turn it back to RGB when the desired media destination calls for RGB. Operating in this manner, the images will match both printed and other higher gamut media.

While the author of the article doesn't explicitly say "send your printer RGB files," it certainly leaves those who don't dig deeper to think that is what it says. In other words, the article is poorly thought out, and I would advise all to steer away from it.

Another clue -- the article makes no mention of GRACoL. Some of the comments/responses do, but nothing in the actual article. Today we're still battling how Adobe sets the default to "SWOP Web" and clients can't understand why a high quality commercial offset press produces the quality of a web press. What do you expect? Profile an image to web characteristics and you going to get the crap 260% TIC of a web press. Computers only do what they are told. And while the color management modules inside of most modern workflows have improved, given a target profile of SWOP Web, even the best CMM in the universe is only going to do what it is told -- turn that image to something a web press can handle, which is setting the bar awfully low.

The better "advice" would be -- use GRACoL.

No, we get the stellar advice to use RGB.

We have a long way to go...

[Magnus]

I work at a large printshop in Sweden and we'v work exactly like the article describes for a couple of years, we also recommend our customers to work that way. The article are not saying that anyone should send RGB-files to the printer (even though that wouldnt be a problem for us as long as the PDF/artwork contains embedded icc profiles), it's about working easy, fast and correct with colormanagement in Indesign. Whats wrong with that?

William: The writer of the article does not mention any specific CMYK-profile cuz thats not whats its about. CMYK is not a work-space it's a destination.

[Lukas Engqvist]

Nothing strange. For us movinig from OPI server wich did the CMYK to using PSD files to be able to utilise the support for live transparency this was the natural way to move. It has a proven track record for stability and trouble free shooting. With images as RGG converting through OPI since mid 80's using the procedure in the article for 99.5% of all jobs since 2002.
(actually if we get a job with CMYK images, with too high TAC fastest and best way to fix is just convert the images to RGB and output)

Would add though use Illustrator technical illustrations in safe CMYK mode! Wich is what we are heading to under point 8, so nothing strange there.

Since PS has no overview of Inklimit It is the most natural way to go.

[Stephen Marsh]

Since PS has no overview of Inklimit It is the most natural way to go.

Of course, one can mouse around in Photoshop with the info palette set to display total ink - however there are better ways to do this in Photoshop!

Lukas, you may be interested in this link...

Curvemeister Total Ink Actions

There was a discussion about checking for TIL/TIC/TAC on the Dan Margulis Applied Color Theory email list and Mike Russell of Curvemeister fame created an action for use for checking total ink limits (to avoid problems with the "ink police" as they are known in some corners of the web!).

This free action is fantastic and my thanks go to Mike for making this tool available to the Photoshop community.


Regards,

Stephen Marsh

[mattbeals]

Laurens mentioned something on the link provided. Many (I didn't say most or all, just "many") already use an RGB workflow internally and at the last minute convert to CMYK. Some even send RGB PDF/X-3 files with the correct output intent defined. They work in RGB and softproof using the output intent to view press color. But here's something to think about. RGB workflows are more flexible for re purposing content than CMYK based workflows. Once you go CMYK you cannot go back to RGB as William points out. The idea of lowest common denominator is a valid argument from a print perspective. However if you have an RGB workflow you can go to the web, mobile, broadcast, cinema, print (in one form or another), etc. As a brand manager, content owner/publisher/etc you have more flexibility to reproduce the art to its highest fidelity for the specific "medium". A CMYK workflow is becoming the "old" way of working as this need becomes important. It's "comfortable" for printers to work and think CMYK only because it is what they have known for so many years. Print is no longer the dominant medium for publishing content. Therefore it is no longer "prepress", it is becoming "pre media". As I said before, we need the flexibility to publish the content in what ever format on whatever medium we want to the highest level of fidelity. If we think in lowest common denominator terms then we produce the best quality on the least capable medium. That doesn't sound like what a brand owner wants to hear... Might as well throw away the Pantone library then, only part of it is able to be reproduced in CMYK. Which happens to be about the lowest common denominator. Diversity is the key. It's not just ink on paper any more. It's not enough to be "just a printer". Printers, and others, that survive long term are not just going to put ink on paper. They are going to be able to re purpose content for their customers. RR Donnelley is not just putting ink on paper. Part of what they do is re purpose content. So the idea of working RGB internally for a publisher and sending final CMYK is not unreasonable. Nor is the idea of sending RGB data and having the print provider make the final separations. Of course if the print provider is providing more services like asset management then they're very likely to be archiving RGB data (if they are planning ahead).

Maybe this is just another one of my notoriously kooky ideas. But in this economy, and in years past, we have to look beyond "print" in our industry and think outside of the press room. Time to start thinking "premedia". If anyone wants to be a contributor to my site (a bit dusty) premediaworld - Home then please let me know.

[Lukas Engqvist]

Of course, one can mouse around in Photoshop with the info palette set to display total ink - however there are better ways to do this in Photoshop!

Lukas, you may be interested in this link...

Curvemeister Total Ink Actions

There was a discussion about checking for TIL/TIC/TAC on the Dan Margulis Applied Color Theory email list and Mike Russell of Curvemeister fame created an action for use for checking total ink limits (to avoid problems with the "ink police" as they are known in some corners of the web!).

This free action is fantastic and my thanks go to Mike for making this tool available to the Photoshop community.

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.

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. The only way to limit the ink would be to convert the photoshop image to Lab and then convert it back again using a different separation profile, then reselecting the inverse of the areas indecated by the Ink police, and filling with the original. Explaining that to someone who wants to create freely but just get what they see on screen is a little tricky in my experience.

I would say it is more important for photoshop users to either work with the limitations of each specific output intent, or to work device independantly… ie RGB. There are exceptions and for that I am very thankfull for smart objects wich means you can actually have adjustment layers in RGB in the embeded RGB object and have channel targetsed adjustments in CMYK in the main CMYK document… but the special scenarios where that is applicable is less than 1% of images, and does require a knowlede of the output intent.
(oh Lab would work just as well as RGB but there is an advantage of having the image gamut and output gamut to be of similar size)

I do keep asking Adobe to include the same interface that we find in Acrobat and InDesign, but with an RGB workflow, where the correct separation profile is selected in InDesign it is not possible to get too much ink.
I have also asked Adobe to consider that when having a working CMYK ICC with and embedded ink limit that Inklimit should be honoured.

[Magnus]

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.

[mattbeals]

Ink coverage is relatively easily taken care of with a good device link profile and Callas pdfToolbox (plug-in, Server or stand alone) or in the RIP. It should be a non-issue for customers for the most part (there's always an exception). But if you're taking in RGB data then it's a non-issue anyways.