Artifacts in PDF?

[Dr Mick Mach]

Working on a book cover to be printed through IngramSpark. Outputting as a pdf  PDF/X1a:2001 as required by IngramSpark.

Getting some weird lines on the resulting pdf file (pictured below) that seem to correspond to the bounding boxes of the images.  I've printed it out on my home inkjet and they don't seem to be showing up there, but not sure if a commercial printer will show.

Any thoughts on why this is happening/does it matter/how to fix?

Thanks

[BobLevine · Accepted solution]

These are stitching artifacts from flattening and shouldn’t print to a high resolution device such as a press. An ink jet? Entirely possible.

That said, if I know the client needs artwork spec’ed for archaic formats, I design accordingly and avoid transparency.

[Dr Mick Mach]

Thanks Bob, good words as always

[Dov Isaacs]

To amplify on Bob Levine's response, PDF/X-1a is a very archaic standard designed as a standard prior to transparency being part of the PDF imaging model. The recommendation by Adobe for a number of years and by virtually all print associations and standards groups is to export PDF/X-4 and to print from that. PDF/X-4 supports live transparency and full ICC color management, i.e. transparency isn't prematurely “flattened” and colors are maintained in their original ICC color spaces until the RIP process.

Every modern day RIP (including those used by IngramSpark) actually produce much higher quality output when presented with PDF content as PDF/X-4 than when presented with PDF/X-1a when the original content is anything other than opaque CMYK content. Requiring conversion of all content to CMYK and flattening of transparency is indicative of a Luddite and “blame the customer” mentality. So sad!

          - Dov

[Dr Mick Mach]

Thanks Dov, just as a quick follow up I noticed Ingram Spark also allows upload in  PDF/X-3:2002   Is this newer (tho still archaic) format a better bet for my files?

This has been my first big project in Indesign and it's been a very 'on the job' software learning experience, hence using transparency and other errors I've learned the hard way.

[Dov Isaacs]

Not any better. PDF/X-3 supports color management but since IngramSpark prohibits anything other than CMYK as handed down from Mt. Sinai (with the tablets), use of PDF/X-3 buys you absolutely nothing over PDF/X-1a since it likewise doesn't support live transparency.

          - Dov

[Dr Mick Mach]

Hah great! (I mean, not great but funny.)  Thanks Dov.  This file conversion stuff is breaking my brain a little.  Much appreciated

[Dov Isaacs]

That's exactly why I lurk around here. 

          - Dov

[Derek Cross]

Would PDF/X-4 be OK for printing to an inkjet printer that has more that colours than CMYK and you're using the printer's software?

[Dov Isaacs]

Absolutely!

If you are printing via a native PDF RIP (i.e., not printing from Acrobat but simply queuing up such a job to a RIP controlling a high fidelity printer such as a 5, 6, 7, or more colorant high quality inkjet device), typically the Output Intent profile is ignored, the CMYK values are printed pretty much as-is, but the color managed RGB (remember we said not to prematurely convert that to CMYK) is mapped into all those extra colorants, typically to vastly expand the available gamut of the device.

If you are printing to a PostScript device controlling such a multiple-ink printer from Acrobat or Reader, since we convert everything to CMYK on the way out to PostScript, you will not see much if any benefit.

If you are printing to a non-PostScript device from Acrobat or Reader, content goes out as RGB and the printer's driver maps that to the specific n-colorants of the printer itself.

          - Dov

[Derek Cross]

Thanks Dov.

[rob day]

is mapped into all those extra colorants, typically to vastly expand the available gamut of the device.

Dov, I think it should be noted that the source RGB space would have to contain the printer's gamut if you are expecting to get at the expanded gamut—a small space like sRGB would clip a large gamut CMYK or CcMmYKk device by a good amount.

If you are printing to a non-PostScript device from Acrobat or Reader, content goes out as RGB and the printer's driver maps that to the specific n-colorants of the printer itself.

Also there have been a number of posts from users printing to lowend printers where the native driver can not correctly print live transparency ("Yucky Discoloured Box Syndrome"). Usually the fix has been to flatten the PDF into a single RGB space on export

[Dov Isaacs]

https://forums.adobe.com/people/rob+day  wrote

is mapped into all those extra colorants, typically to vastly expand the available gamut of the device.

Dov, I think it should be noted that the source RGB space would have to contain the printer's gamut if you are expecting to get at the expanded gamut—a small space like sRGB would clip a large gamut CMYK or CcMmYKk device by a good amount.

If you are printing to a non-PostScript device from Acrobat or Reader, content goes out as RGB and the printer's driver maps that to the specific n-colorants of the printer itself.

Also there have been a number of posts from users printing to lowend printers where the native driver can not correctly print live transparency ("Yucky Discoloured Box Syndrome"). Usually the fix has been to flatten the PDF into a single RGB space on export

Excellent points!

Typically when you are dealing with what I will describe as the typical native CMYK content, large gamut CMYK is not an issue. It is certainly not the working space of the vast majority of CMYK content providers. And there is no way to produce content in CcMmYKk directly. Typically, content in whatever RGB you have will be what takes advantage of large gamut CMYK, CcMmYKk, CMYKOG, or similar colorant-based printing. And (I think) obviously, the wider the gamut you start off with in RGB, the more likely you will be able to take advantage of all the gamut available with high fidelity color printing. That's why if you shoot RAW, you should directly convert to Adobe RGB or similar higher gamut RGB color spaces than create sRGB. Amazing how many folks think that “converting” an sRGB image to Adobe RGB is going to increase gamut (it obviously doesn't!).

And yes, “low end printers” can be exceptionally problematic and even more so, lousy printer drivers that come with some “low end printers” as well as “high end printers.” Drivers are a critical element in any non-direct PDF printing scenario.

          - Dov

[Miguel Agawin]

Mr. Isaacs, Thank you for all your insight in this thread! What is your view on flattening and converting colour in-house (Acrobat) for the purpose of having a consistent outcome/proof an ad client can approve?

[Dov Isaacs]

Mr. Isaacs, Thank you for all your insight in this thread! What is your view on flattening and converting colour in-house (Acrobat) for the purpose of having a consistent outcome/proof an ad client can approve?

That method doesn't guarantee that the client will be able to properly proof anything since the CMYK-only PDF will be converted to RGB for display by whatever is displaying the PDF file.

The only way to really approximate what will be printed is to (1) produce PDF/X-4 with live transparency and no color conversions, making sure to have an output intent profile matching the actual printing conditions, (2) make sure that the client is viewing the content in Acrobat Pro with Overprint Preview enabled, and (3) that the client has a monitor that is reasonably color-calibrated. Otherwise, it is a real crap-shoot!

[rob day]

You do have to be aware of how the client is going to view the PDF.

None of my clients have CC subscriptions, so expecting the review to be in AcrobatPro’s Output Preview might not be possible. It’s worth noting that Acrobat Reader also will use the PDF/X-4 or PDF/X-1a output intent profile to softproof color. Both AcrobatPro and Reader have a Page Display Use Overprint Preview, which will display out-of-gamut RGB color in the output intent’s space if it is turned on—X-1a can’t have out-of-gamut color, so it wouldn’t matter in that case.

This ID page has a mix of CMYK and RGB color, which display’s as document CMYK as long as Overprint/Separation Preview is turned on:

Exported to PDF/X-4 (ISO Coated V2 300%). Acrobat Reader will display all of the color in the output intent profile’s space, but only if the client has Use Overprint Preview turned on, otherwise the unprintable RGB color will soft proof unchanged:

PDF/X-1a:

[runninghead_design]

Came to this thread as it popped up first in Search for the topic of "Artefacts in Adobe PDF".
Got to say, it's shocking how Adobe PDF leaves so much crap in the file that needs manual cleaning up.
Sure, it may only show on laser printers and on screen in previews but if there's no way to be 100% sure your files won't mess up (especially when it comes to high-budget critical print jobs) then I'm sure I'm not the first to wonder why the software isn't better? Whether it's really necessary or not, I can manually remove so many empty boxes and stray objects from a PDF that I'm left unable to trust AI or Acrobat for important jobs.

[BGCC-Comm]

I have a 1-2 pixel artifact coming from the other side of a spread, yet the bleed settings from Indesign are set to 0. How is this possible unless Acrobat is pulling data from beyond the 0? How do I export a PDF from InDesign without left/right spread artifacts?

[BGCC-Comm]

I have found an imperfect solution. I am able to use Acrobat Pro and manually select and delete the orphaned artifacts from the adjacent spreads and then resave the PDF. 

[rob day]

Stitching artifacts due to flattening are not objects, they are a result of display anti-aliasing. So if you can select and delete them something else is going on and they likely exist in the original page layout.