PDF/X4 and output intents

[jesse]

2 questions.

1) Is it possible to create a compliant PDF/X4 from the CS3 suite (namely acrobat 8 and InDesign CS3)

and

2) Does PDF/X4 require an output intent, or can I let the RIP convert the embedded color information straight to the media gamut it's being printed to?

 

[toronar]

2 questions.

1) Is it possible to create a compliant PDF/X4 from the CS3 suite (namely acrobat 8 and InDesign CS3)



2) Does PDF/X4 require an output intent, or can I let the RIP convert the embedded color information straight to the media gamut it's being printed to?

ad 1)
I think InDesign CS3 only had preliminary PDF/X4-Support and did not set some required date-fields; but other than that the PDF/X4-Export from IDCS3 is compliant.

ad 2)
PDF/X4 of course requires an output intent, as does every PDF/X-spec.

 

[leonardr]

1) Is it possible to create a compliant PDF/X4 from the CS3 suite (namely acrobat 8 and InDesign CS3)

No, only a DRAFT version of the PDF/X-4 standard was supported by those programs. The files you create are VERY VERY CLOSE to PDF/X-4 but they will not pass validation.

2) Does PDF/X4 require an output intent, or can I let the RIP convert the embedded color information straight to the media gamut it's being printed to?

Yes! And as Toronar points out, ALL PDF/X standards require an OutputIntent. PDF/X-3, X-4 and X-5 all require that the OutputIntent consist of an embedded ICC profile. PDF/X-4p allows for that profile to be external (referenced by URL).

 

[jesse]

Yes! And as Toronar points out, ALL PDF/X standards require an OutputIntent. PDF/X-3, X-4 and X-5 all require that the OutputIntent consist of an embedded ICC profile. PDF/X-4p allows for that profile to be external (referenced by URL).

Does the PDF/X standard make sense in a workflow where you have variable media gamuts, and you want to get the best color from each device? (I half know these answers, but I'm not 100% confident, and I need to explain it to "decision makers")

We need a solid PDF preset for our workflow, and because most of our staff doesn't completely understand what all is involved in saving PDF's, they've decided they need to use a predefined standard, so they've chosen PDF/X3 with the output intent as USWCSv2. I'd like let the RIP software handle the color conversion to the media for the best possible color (one off colorful posters on inkjets), but we lack the knowledge to make a decision we can be sure of. Are there any PDF standards out there that are PDF/X "like", but don't require an output intent?

 

[leonardr]

Does the PDF/X standard make sense in a workflow where you have variable media gamuts, and you want to get the best color from each device? (I half know these answers, but I'm not 100% confident, and I need to explain it to "decision makers")

The whole point of the OutputIntent is that since you know what profile the colors were prepared for, you can do proper color management and transform from that profile to the one on your RIP. So YES - it makes 100% sense, and in fact is the only reliable solution for proper color management.

We need a solid PDF preset for our workflow, and because most of our staff doesn't completely understand what all is involved in saving PDF's, they've decided they need to use a predefined standard, so they've chosen PDF/X3 with the output intent as USWCSv2.

BUT are they actually working in that profile or just picking it because it's the "flavor of the month"? As noted above, the OutputIntent MUST match the actual profile(s) being used to create/edit the content in the file. If it doesn't match what was actually used - then there is no point putting it in.

I'd like let the RIP software handle the color conversion to the media for the best possible color (one off colorful posters on inkjets), but we lack the knowledge to make a decision we can be sure of. Are there any PDF standards out there that are PDF/X "like", but don't require an output intent?

If you are going to be working with different variants of the same profile, but all based on the same characterization data (eg. TR001), then look at PDF/X-1a. It is about pure CMYK+Spot data that is characterized but not profiled. in that case, you can then play with the specifics on the press as the OutputIntent is not a profile but simply the characterization...

 

[Lukas Engqvist]

Working to different Gamuts, I would be a little reserved, even with an x3. How are you dealing with transparency? If you use an x3, x4 or x5 is it defined the dendering between embedded ICC's and output intent? CMMs and enabled/disabled black point compenstion and rendering intent will mean that there are still a few "details" left for interpretation.

A PDFx1a with an out put intent will have each colour consistently handled, regardless of rendering intent and it does not allow transparency, ony issue there would be spotcolours that are converted interecting with transparency via overprint.

 

[jesse]

Working to different Gamuts, I would be a little reserved, even with an x3. How are you dealing with transparency? If you use an x3, x4 or x5 is it defined the dendering between embedded ICC's and output intent? CMMs and enabled/disabled black point compenstion and rendering intent will mean that there are still a few "details" left for interpretation.

A PDFx1a with an out put intent will have each colour consistently handled, regardless of rendering intent and it does not allow transparency, ony issue there would be spotcolours that are converted interecting with transparency via overprint.

The inkjets and media we use offer a gamut much larger than most standard CMYK working spaces, and the design work is usually done in adobeRGB. Our RIP has had issues with transparency, so we try to flatten it before sending it to the RIP (and our lambda RIP is outdated and can't digest newer features.)

I'd like to use a PDF format that will ensure the best color conversion per media, and not necessarily make posters match from device to device. The output intent, depending on the context you take this comment in, makes PDF's device dependent (in that we're using a lowest common denominator, rather than getting the best results from each device).

We need a sort of "one size fits all" format that we can rely on, and we print to a wide range of gamuts.

 

[leonardr]

The inkjets and media we use offer a gamut much larger than most standard CMYK working spaces, and the design work is usually done in adobeRGB.

OK - that's good!

Our RIP has had issues with transparency, so we try to flatten it before sending it to the RIP (and our lambda RIP is outdated and can't digest newer features.)

And that's bad. How about upgrading the RIP to something that can handle modern features? For that matter, is the RIP even PDF/X (any flavor) aware??

[/QUOTE]The output intent, depending on the context you take this comment in, makes PDF's device dependent (in that we're using a lowest common denominator, rather than getting the best results from each device).[/QUOTE]

NO! Exactly the opposite! OutputIntent tells you WHAT the colors were produced FOR, so that you can then use standard color management to adjust them at the final device.

If you are working in RGB anyway - why not produce an RGB-based PDF/X-3 (or X-4) file? PDF/X doesn't require CMYK - it just requires the use of an OutputIntent, which can also be RGB (or even Gray). Then the RIP itself can do the RGB->XXXX transform having the highest gamma, etc.

 

[jesse]

And that's bad. How about upgrading the RIP to something that can handle modern features? For that matter, is the RIP even PDF/X (any flavor) aware??

No, it is not PDF/X aware, but just yesterday I began testing a 30 day demo of EFI Fiery, and so far, so good. Now if I can just secure the funds. :¬P

The output intent, depending on the context you take this comment in, makes PDF's device dependent (in that we're using a lowest common denominator, rather than getting the best results from each device).

NO! Exactly the opposite! OutputIntent tells you WHAT the colors were produced FOR, so that you can then use standard color management to adjust them at the final device.

Right, but (disregarding the next comment, which would change my response to this comment, so just play along ;¬) ) we have people who want to use GRACoL as the output intent, which then limits everything to that color space, which is where I'm getting the "device dependent" logic. We'd never do any better than GRACoL in that instance. I'm trying to convince people otherwise. Your next suggestion is what I was looking for, but didn't know if it would work:

If you are working in RGB anyway - why not produce an RGB-based PDF/X-3 (or X-4) file? PDF/X doesn't require CMYK - it just requires the use of an OutputIntent, which can also be RGB (or even Gray). Then the RIP itself can do the RGB->XXXX transform having the highest gamma, etc.

We have CS3, which won't create a valid PDF/X4 (or am I mistaken) and due to the current financial "crisis", as a company we've decided to wait for CS5 before upgrading. I'm all for PDF/X4, but I just have to accept what those up the ladder decide.

So, if we go with PDF/X3, and use AdobeRGB1998 as the output intent, the RIP should then map the output intent to the media? We can choose a rendering intent to render the output intent result to the media gamut, and that won't "double dip" the image so-to-speak? I guess assuming it's going from adobeRGB to adobeRGB, technically, there should be no change at all, correct?

Thank you for your help!! What you said made sense, so I hope I'm not being redundant with my questions. I'm just trying to make sure I completely understand what you're telling me.

 

[leonardr]

So, if we go with PDF/X3, and use AdobeRGB1998 as the output intent, the RIP should then map the output intent to the media? We can choose a rendering intent to render the output intent result to the media gamut, and that won't "double dip" the image so-to-speak? I guess assuming it's going from adobeRGB to adobeRGB, technically, there should be no change at all, correct?

BINGO on all counts!

 

[jesse]

So, I tried this yesterday, and I couldn't select AdobeRGB1998 as the output intent. It was in the same folder as all my other choices, but distiller wouldn't make it available. Aside from linking to it (which I'd like to avoid), what can I do to make it available?

 

[michaelejahn]

Indeed - you have it. I created a silly example to make a point for a "output intent" discussion once that may help you grasp what is actually happening - this example is very contrived and hardly 'real world'

take a peek and perhaps it may help you conceptually...

PDF/X Output Intent procedure...

 

[rich apollo]

So, I tried this yesterday, and I couldn't select AdobeRGB1998 as the output intent. It was in the same folder as all my other choices, but distiller wouldn't make it available. Aside from linking to it (which I'd like to avoid), what can I do to make it available?

It looks like the output intent profile must be an output profile. AdobeRGB is a working space profile. I don't know if that is a PDF/X requirement or an Adobe requirement.

You cannot convert to a working space profile upon output, either. If/when PDF/A is supported in ID, then that will have to change.

 

[leonardr]

So, I tried this yesterday, and I couldn't select AdobeRGB1998 as the output intent. It was in the same folder as all my other choices, but distiller wouldn't make it available. Aside from linking to it (which I'd like to avoid), what can I do to make it available?

Looks like a bug in Distiller, that it won't allow you to choose that profile...It works just fine in Acrobat itself (preflight and Save As) as well as the other Creative Suite apps.