Re: Photoshop 7/Quark 5 Workflow
Re: Photoshop 7/Quark 5 Workflow
- Subject: Re: Photoshop 7/Quark 5 Workflow
- From: Chris Murphy <email@hidden>
- Date: Sat, 20 Mar 2004 12:13:26 -0700
On Mar 20, 2004, at 8:28 AM, Pablo Roufogalis L. wrote:
Hello to all.
I have read bad things in this list about using Quark 5 as the hub of
a CMS workflow, either RGB or CMYK-based for print output.
There is a disconnect between what is logical and what it actually
does. For example if you have the "Color Manage CMYK Sources to CMYK
Destinations" box unchecked, then you can be assured that regardless of
embedded or assumed profiles for placed images, CMYK images will never
be converted - TO A CMYK DESTINATION. It's a good safe feature, and it
works exactly as it says it will work, but there are some problems with
it.
1. For tagged images, QuarkCMS still uses the embedded profile as
source for on-screen preview.
2. For untagged images, QuarkCMS will assume the Default CMYK profile
for images as source for on-screen preview.
3. If you try to proof to a CMYK device, RGB images get proofed
correctly, but CMYK images do not because the destination (proofer) is
CMYK. So to proof you must turn off this checkbox - which may cause
embedded profiles to get used that you don't intend to use when
printing the document.
So everything works as designed, it's just that you have to be really
careful how you put together the QuarkXPress document. A complex layout
can rapidly become an impossible color management juggling act where
the end user is having to think about color management a lot more than
the application. But for simple stuff, it's usable.
What would be missing in this workflow?:
1) Prepping the files in Photoshop and saving either in AdobeRGB or
separating to CMYK using the press profile.
2) Importing into Quark being careful regarding profile assignment to
each individual image and 'manage source to destination' checkboxes.
3) Proofing full pages using the 'Composites Simulates Separation'
option. I understand there's a limitation here with the Absolute
Colorimetric Rendering Intent but that seems a minor issue. Was this
corrected in version 6?
4) Separate/print normally.
Composite Simulates Separation does not have rendering intent control.
I'm pretty sure it uses the Composite profile default rendering intent,
but it might be Relative Colorimetric hardwired. I forget. This is the
same in 6.0 and 6.1.
If I understand correctly, I wouldn't have CM for EPS files nor for
color elements created in Quark itself.
Not for EPS, but yes for solids.
It was proposed in earlier threads that it's better to turn off CM in
Quark and do it in the pdf environment. I wonder if it makes sense to
switch from a simple Quark/RIP workflow to a pdf-based workflow (at
least one additional step, plus new hardware and software) just for
the additional CM capabilities.
That would require a normalized workflow so that you can assume source
profiles once the PDF is made. This is because any profiles in non-EPS
files placed in QuarkXPress do not have their profiles retained when
PostScript (or PDF directly from QXP) is generated.
FWIW the behavior of QuarkXPress is documented in greater detail in
Real World Color Management. And the next edition will include changes
in QuarkXPress 6.1.
Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management"
Published by PeachPit Press (ISBN 0-201-77340-6)
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.