Pdf/x1-a

[Sari]

From what I have been reading lately, Pdf/X1-A is supposed to be the 'be all end all' way to make pdfs. "It's fail safe". Well we have problems printing PDF/X1-A files. A designer used an .eps from Illustrator and 'pasted into' a graphic in Indesign. Used a MULTIPLY effect @35%, then exported the pdf using PDF/X-1A default. When the file printed it lost the transparency. Even when the pdf was made, if you turned off Simulate Overprint you could see the file was wrong. Is there something we are missing here? The "High Quality" pdf setting worked better. We want to be able to give our designers a standard pdf to use since they try to "Quick Print" and bypass prepress.

thanks for the help

 

[Stephen Marsh]

The PDF/X formats are not a silver bullet and there are different “flavours” intended for different purposes, workflows, software etc.

PDF/X-1a does not support transparency, which is flattened using the source apps native method (PDF 1.3, Acrobat 4 or higher) and RGB/Lab is not supported either. This is often referred to as an “early binding” format.

High Quality Print setting retains transparency (PDF 1.4, Acrobat 5 or higher).

You may find that PDF/X-4 may be a better choice if your RIP software handles transparency or you wish to defer flattening at PDF creation time (however RGB/Lab colours are still possible). This is often referred to as an “late binding” format.

There is nothing wrong with creating your own “in-house” standard based on whatever settings you prefer. For example, I personally think that the default PDF/X flavours are lacking as they do not include the “tagged PDF structure” by default and that one has to make a custom preset to include this very useful feature that can help with downstream automation and repurposing (even for a print “outputcentric” format such as PDF/X, creating a tagged PDF structure can be beneficial for some print/output workflows).



Stephen Marsh

 

[Joe]

PDF/X1a hasn't ben the 'be all end all' way to make pdfs for quite some time now. PDF/X1a might still be useful if you are running an ancient RIP (or a Fiery) that can't handle transparency.


PDF/X-4 is the proper one to use.

 

[arossetti]

Since when could a Fiery not handle transparencies?

 

[Joe]

When you send a PDF with transparency to it directly via hotfolder. And sometimes even that will work but a lot of times it won't. Depends on how the file was constructed. If you print from an application to it, printing flattens it anyway and usually works better.

 

[Ulrich]

From what I have been reading lately, Pdf/X1-A is supposed to be the 'be all end all' way to make pdfs. "It's fail safe".

PDF/x is a standard for printing. As Stephen Marsh and Joe already explained, there are different "versions" and strategies and limitations regarding transparencys (and some others, regarding font-technology, file format JPEG2000...).

The x in the name stands for blind exchange. PDF/x whithout colormanagement is not possible, a basic feature for this standard is an OutputIntent (OI), a finally to the PDF file tagged profile as an information to the service provider (prepress or printer) for what printing condition this file is separated (x-1) or at least still to convert by him (x-3 and x-4): Uncoated, coated, sheetfed, web, gravure, etc. - as a service provider you have to know, which profile - which OI - is for what condition...

x-1 means all colors are CMYK, grey, separation color (ALL) or deviceN (Spotcolor) and no with profiles tagged objects anymore, but one profile as OI. No transparencys!

x-3 all colors are CMYK, grey, separation color (ALL), deviceN (Spotcolor) or RGB with maybe different profiles tagged objects (ICCbased) are to convert by the service provider to CMYK according the OI, also no transparencies.

x-3 didn´t work well in praxis, because also cmyk-objects can be tagged with profiles and that can cause unpredictable confusion by flattening the transparency or 4c separated black, which was former 100K (there is even a transparency colorspace CMYK or RGB, not only a document CMYK or RGB working-space...)

x-4 same colorspaces as in x-3 and Lab, but now transparency is kept and not flattened

Every x-1 is also a valid x-3 and/or x-4, every x-3 is a valid x-4, but a x-4 can be, but not automatically a x-3 or a x-1 and a x-3 is not automatically a valid x-1 ...


I understood Early binding, intermediate binding and late binding this way:
early means all objects placed in the layout are already CMYK, grey or Spotcolor (DeviceN) and of course in the exported PDF/x-1
intermediate allows you to place profiled RGB-Objects in the layout, but by export into a PDF they will be converted into cmyk. So you don´t need a special CMYK-separation for each printing condition for layout.
late means the service provider at least had to convert from (tagged) RGB (or Lab) into CMYK regarding the OI.

If the Preview (look at the name!) in Acrobat shows you for an example only SWOPcoatedv2, than your working space CMYK in Acrobat is defined with that profile (and automatically for that web-offset-coated-condition) and you see a preview how untagged CMYK-objects and tagged or not tagged RGB objects in the pdf will be printed after a neccesary convertion.
If there is to read Printing Condition: GraCoL2006, than an OI is in the PDF and you should see a Preview (!) predicting the converted results for tagged objects regarding the OI, which can be different of course from your working space.


PDF/x-1 is agreed as "fail save", because it´s the condition after all converting action and flattening that is need: If something is wrong, you should see it in the Acrobat preview.
But sometimes there are problems with flattened Spotcolors (Nchannel) and flattened objects could not be trapped in the RIP as in a PDF/x-4 if neccessary.

Otherwise in a PDF/x-4 with transparencies your Preview shows only the truth, if it´s for sure the file will be ripped with an APPE and not with a ps-based tecnology (FIERY) and might be overprinting but tagged objects (ICCbased) will cause overprint in the print that the preview don´t predict. The TAC (Total area coverage) could be also a problem by some transparency situations, they couldn´t be handled with a color server for ink optimization as an PDF/x-1.

if you turned off Simulate Overprint you could see the file was wrong

?

Normally (using professionel Fiery or APPE RIP´s) the other direction shows the truth...


Please correct, what is wrong,

Ulrich

 

[abc]

Sari
Effectively if it has live transparency then it's not a valid PDF/X-1a. All transparency should be flattened.
I would suggest you preflight the PDF with one of the GWG preflight settings that are based on PDF/X-1a, I would expect you to get an error

 

[Glenn McDowall]

InDesign will cheat with transparency and can replace (during flattening) with overprinting DeviceN if it is a spot colour fading to nothing sat on top of cmyk. This doesn't break PDFX-1a rules as there is no transparency and spot colours are allowed. The problem comes when you try to convert the pdf to cmyk only. the converted object becomes cmyk and now the overprint commands only affect empty channels, the original post reads like this is maybe the source of the problem? Its easy to fix by converting the spots to cmyk in InDesign's Ink Manager, and then it will flatten properly. Not so easy to fix on a pdf level.