Re: ICC in PDF / iQueue
Re: ICC in PDF / iQueue
- Subject: Re: ICC in PDF / iQueue
- From: Joel <email@hidden>
- Date: Sat, 11 Aug 2001 09:50:30 -0500
Henrik Holmegaard wrote:
...In a sense I would agree except that PDF is already
object-based and could be married to XML architectures.
Which makes perfect sense with the development of job definition
format (JDF) being aimed at XML support. Properly tagged PDF being a
first step in such a workflow.
...The only sensible way for
this to work is never to use Distiller in the first place, and export
PDF 1.3 directly the way InDesign does...
And we all know how Quark currently handles that. But to do so
wouldn't that require a marriage Quark doesn't want and, perhaps,
Adobe does?
If Adobe gets InDesign 2.0 up to speed and fixes the ICC
implementation so intents aren't used symmetrically (Lab to CMYK =
CMYK to Lab), then the superior type handling in InDesign will make
life hard for QuarkXPress that relies on ATM to function at all.
I was just about to ask an incredibly stupid question (even for me!) so
thank you for the following clarification:
ID152 works the way it should, say Perceptual from RGB working space
to simulation space, and when Simulate Separation Printer is enabled
you get an impeccable soft proof: Relative Colorimetric with no black
point compensation so the white is matched relatively and the black
is matched absolutely. Result: Image shadows soft proof as light as
they truly are.
Having not gone so far with ID151 as I should...ID uses the default
intent of the assigned profile when making PDF: Is this not so? And,
in the case of Relative Colormetric, is Simulate Separation Printer
just another name for BPC?
And when the same color space is specified for both composite and
seperation what does it mean when toggling SSP on or off has no
affect on the output?
ps: no need to answer...just writing out loud. :}
--
joel johnstone - designtype
Winnipeg Manitoba Canada
(Monitoring the full gamut of a confused spectrum)