Viewing Transparencide
When Tim Cole and Rufus Deuchler posted their “Stop Stupid PDF Syndrome Now” video, they brought to light in a humorous way the effects of transparency flattening. The only way to preserve live transparency, device-independent color, and other fragile properties which are destroyed by using a PostScript workflow is to switch to a native PDF workflow like that offered by the Adobe PDF Print Engine RIPs.
I wrote about the Adobe PDF Print Engine recently, and I promised to write more about advantages of the APPE workflow so this seems like a good time. In the comments written about the video, some questioned the value of saving transparency, and I thought it might be useful to provide a visual example. It’s important to work with your commercial printer: Simply sending them a PDF/X-4 file which, as I wrote in my previous posting, preserves transparency and device independence, is useless unless they have a PDF workflow which can use it!
James Wamser of Sells Printing, an early adopter of the APPE who I quoted in my previous posting, suggests that one of the best reasons to preserve transparency is to keep the PDF live and editable. This can be immensely useful if last-minute changes need to be made after the PDF has been sent to the printer. Flattening transparency immediately breaks objects into small pieces, simulating the appearance of the transparent artwork, but “killing” its editability. Below is an InDesign file which includes a placed Photoshop image with transparency. On the right, you see the InDesign file with the Photoshop image frame selected. By choosing Edit Original on the Links panel (or Option/Alt-double-clicking), the placed Photoshop image is opened. In Photoshop, the checkerboard pattern indicates the transparent background of the image.
Now imagine that you want to send this layout to the printer by creating a PDF file. The printer has instructed you to create a PDF/X-1a file which requires that any transparency be flattened. Later, if the printer needed to edit that placed image, perhaps to perform a color correction, it’s impossible. If you open the PDF/X-1a file in Acrobat Professional, you’ll see that all the objects on the page have been broken into fragments. The editability has been destroyed.
On the other hand, in a live transparency, native PDF workflow, you can create the PDF using the PDF/X-4 preset in InDesign CS3 (you could also choose Acrobat 5 compatibility with another PDF preset). Using this PDF preset preserves live transparency. If you open the resulting PDF file in Acrobat, you can select the image with the Touchup Object tool (found on the Advanced Editing toolbar), and choose to edit the placed image in Photoshop. As you can see below, the Photoshop image is intact, and fully editable. (The PDF file is on the right, the file opened in Photoshop is on the left.)
Since I wrote last, I’ve discovered that Adobe has posted three case studies of printers around the world who are successfully using the Adobe PDF Print Engine. Here’s a link to their stories. Here are a couple quotes which indicate how pleased they are with the results:
Tony McLachlan, Prepress Coordinator of the University of Southern Queensland in Australia reported, “The combination of reliability and flexibility means we get jobs done faster and more accurately. Files are rendering twice as fast as they would compared to our previous system. Our new internal workflow definitely results in faster turnaround on jobs and a better bottom line.”
Patrick Stuart, Technology Marketing Director of The Bureau of Engraving Inc. in Minnesota commented, “With the Adobe PDF Print Engine solution, our ability to get everything right the first time is close to approaching 100%.”
Those of us who have experienced the problems that flattened transparency can bring?text or thin lines getting thicker, transparent effects disappearing, stitching, and so on?will be very happy when more printers adopt the new technology. After my last posting, Anne-Marie expressed the wish that Adobe’s Partner Finder, which can be used to find print service providers who support Adobe products, would list commercial printers who are using APPE. You’ll be happy to know that David, Anne-Marie, and I have expressed that desire to the appropriate Adobe staff people. Hopefully, the Partner Finder will be updated to include that criterion.
Printers are often slow to adopt new technology, but hopefully they’ll come to recognize that a native PDF workflow is a win-win situation for both them and their customers.
 |
Nice post with a lot of good explanations of APPEs advantages!
Thx and greatings from Austria
Martin
This post comes a little too late for me, please take my needs into account in future and post them when I need them (only joking guys)
Got my magazine back from the printers, and all the effort I went through to make my objects on the page have no “white box”, even the proofs they sent didn’t have these “white boxes” behind the image.
Alas, a double page spread that I spent hours making just right, came out with these white boxes behind the images. I was gutted.
I really could have used these posts yesterday, but it’s too late the magazines are delivered and all.
But by gum I’ll make sure I’ll pass on these posts and give them an earfull.
Actually, what I’m really having trouble with is placed InDesign files that have spot colours, anytime I apply a drop shadow to the files, because they look very flat just placed in, I have a massive transparency issues.
I guess I’ll figure it out some day.
That should be InDesign files that have transparency already in there, then placed in Indesign, that has transparency on that page, and then applying a drop shadow. It might be quicker and less worrisome and I know it works and I know the printers don’t have a problem with that.
Arrrggh, that should be “might be quicker to place a pdf” gosh I can’t finish a sentence this morning.
About a month ago, I was able to persuade a printer I’m using here in Oslo for a magazine project to upgrade his RIP to PDF/X4. My files were the first he received in this format, and while he said things seemed to work OK, he asked me to submit flattened PDFs. So I worked my derriere off to insure all text was on top layers, etc., and then I gave him BOTH transparent and flattened PDFs. He ended up using, alas, the flattened version — I say alas, for there was ONE text box I had forgotten to move to the top text layer, and that got that annoying thin, white bounding box around it. So if the printer had had balls enough to use my transparent PDF, that nuisance would have been non-existent. Next time, I’m *insisting* that he use transparent PDF — and he’ll have no choice, for that’s the only kind of file he’ll be getting from me!
Clearly, changing workflows requires an expenditure of effort. It’s hard for printers to leave behind methods that they’re familiar with. As we can see in your stories, there may be a little pain in the process.
People who question the value of avoiding flattening probably aren’t fully aware of what they’re losing, either from a design, production or archiving perspective.
The purpose of the video was (at the risk of sounding very, very trite) to raise awareness and stimulate discussion…because the advent of native PDF RIPs is a pretty major leap forward for print workflows.
Today’s software enables designers to go well beyond what Postscript was originally designed to do. Transparency is the prime example. Postscript is an opaque imaging model. PDF is not. If I can avoid having to convert a layout to Postscript, I avoid dumbing down my documents.
Flattening is a simulation of transparency that is necessary if you’ve got a Postscript workflow…a necessary evil if you will.
Print providers that are using these new PDF RIPs (like James and the others quoted on the Adobe site) are experiencing first hand how many problems simply don’t occur when imaging transparency-intensive customer files (readers can check out my conversation with James on my InDesign Backchannel Adobe blog to hear it James’ own words).
These RIPs are faster and they deliver more predictable results…because they’re able to image directly from PDF rather than a potentially complicated Postscript jigsaw puzzle.
Thanks for furthering the conversation, Steve.
I don’t have a problem with live transparency at all. I think it’s great. I just wish there was a button to export my file as a pdf exactly as I see it on screen.
I’ve delivered PDF x1a files to printers where the file won’t go through the RIP.
I will submit any pdf that will print correctly, but I’m sick and tired of pdf’s don’t print correctly. Like a placement of am indesign book cover, I placed that and it didn’t print correctly.
Well you might say all my book covers were incorrect. That wasn’t so, as all my book covers were created the exact same way, in the same file and this cover decided it’s own fate.
People can sit here and criticise my pdf making abilities, but I just want something that works.
Whether it’s a bolistic PDF or a static PDF, I don’t care, I just want to print what I see on screen to print format.
I realise I might be looked down on for the above comments. I do think it has become way tooo user involved. And as that is great in many ways, I hope my views are perceived as argumentive.
mmm… that seemed a bit snotty, but it was intended that way. All the information I get from here is fantastic and I can’t thank you guys enough.
But you know, I still want a PDF to print as I see it on screen. I do get disappointed when I get my prints back and the RIP has torn my PDF a new one.
I use about 4 or 5 different printers and I do have PDF settings for each one.
I may still be a little annoyed over my magazine coming back from the printers with white boxes around images, but I think I have a small right to be annoyed over it, and I seem to vent it here. So sorry if I’m off topic or anything, but I’m venting, I’m sure we’ve all been there.
Eugene, the whole point of the PDF Print Engine is to do exactly what you describe.
Tim that is good to know. I have to say I enjoyed your video on the subject.
When I start working with a new (offset) printer I ask them to send me a PDF joboptions file with their preferred settings. If they don’t want to or don’t know what I’m talking about (yes, I’ve had that happen once) I don’t work with them at all as I can’t make promises to my customers.
Anyway… By having them supply the joboptions file, I know my settings will be correct for them to print without issues. And seeing how I’m a “layer whore” — more so than I am an ammo whore on Xbox Live — I never worry about object or layer order anyway since everything (text, images, shapes, and then often they’re sub-devided too) is separated like crazy.
Eugene, you said something about ID files placed in another ID file, and that ended up giving undesirable results. I’ve had major problems with placed ID files also, costing me quite some money in re-prints, so I’ve gone back to exporting to PDF and placing those. Yes it’s slightly more work, yes it’s harder to make changes, but at least it’s reliable.
Roland, glad to hear I’m not the only having these problems. I too get the joboptions from the printers, and have come across those who don’t know what they are. For know I’ll have to get back to PDF placing rather than InDesign file placing, the risk is just too much. Until I understand it better, I’ll have to go with what I know.
Eugene and Roland: Can you confirm that you’ve had this problem (printing imported INDD files) with 5.02? There were problems with 5.0, but my understanding was that they were fixed in 5.02.
Yes, I do have problems. I have my book covers that I created in InDesign, all set up the same way, all the book covers are in the one file.
This is set up with a solid colour with a screen at the top and bottom to darken those areas of the book cover, which print great on their own, I have text, illustrator vectors in there, no raster images.
I import one of the InD pages into my publication, i.e., one book cover.
I copied the file 3 times, rotated them at different angles, applied a drop shadow.
Exports look good on PDF, it prints great, I got my proofs back, no problem. And then when I got the printed version back the middle book cover didn’t have any colour, it was just white, and the 3 instances of the InD placed page had white boxes around them.
I know it’s probably a RIP problem.
But here’s the other thing. The book covers recently went into our Publications Catalogue. There were 24 book covers, all done the exact same way all in one InD file, with the screen at the top and bottom to make the colour darker.
All the book covers printed fine in the publication, bar 1 cover, where a solid colour was there instead of the two screens set up in it, it ignored the screen, why just on this one particular page.
It could be a RIP problem, but it wasn’t like that on the proofs. Whereas I know it is probably a RIP problem, it still begs the question, why did one page of the InD file just not work like the rest of the pages in the InD file, all the other InD pages printed fine?
And to go along with that, I also made up an advert to go into our magazine, it gets printed elsewhere too, and I was placing the InDesign file. When I printed it the whole thing bitmapped, for some reason, this InD file didn’t want to be placed, where my other InD files that I had placed elsewhere in the publication printed fine. I then had to open the file, copy everything into the magazine and do it that way, then it printed fine.
So there’s some of my multiple problems that I’ve had recently.
>Exports look good on PDF, it prints great, I got my proofs back, no problem. And then when I got the printed version back the middle book cover didn?t have any colour, it was just white, and the 3 instances of the InD placed page had white boxes around them. I know it?s probably a RIP problem.
So what did the printer say? Clearly, they’re proofing your pages on a different RIP than their printing your job on. Perhaps (if you have the choice), this is NOT the printer to be sending the jobs with placed INDD or complex transparency.
Eugene, that’s interesting, but it sounds as though you were sending PDFs to the printer, not the INDD files, right? So it’s just as likely to be a problem with the PDF. Once it’s a PDF, Acrobat has no idea where the images/objects came from. That is, I don’t think there’s any difference between an image that came in as a PDF and one that came in as an INDD file, after it’s been flattened to PDF/X1a.
Steve, that is what I think is happening at the printers, but I don’t know why someone would do that? Although I’ve not spoken to the printers about it, I’ve wanted to, I was told not to by the superiors.
David, the way you put it is interesting. Although, I don’t have a problem with InD files that I pdf and then place, it seems to be concentrated just on placed InD files.
Although I think Steve and David hit the nail on the head there.
For the life of me I don’t understand why a placed InD file in a flattened PDF prints differently to a placed PDF in a flattened PDF.
But, you know, if you guys aren’t having problems with it, then it must be down to the RIP the printers are using.
Here’s a strange question – does a placed InDesign file that has transparency flattened on export to pdf?
Eugene wrote: Here?s a strange question – does a placed InDesign file that has transparency flattened on export to pdf?
As long as you Expert using PDF Version 1.4, the transparency does not get flattened even when placing an InDesign file inside an InDesign file.
Great question!
JW
David, I emailed with you about the problems I’ve had with placed INDD files.
I print from InDesign 5.02 directly to my Canon CLC4040 printer/copier, and placed images (PSD with clipping masks) in the placed INDD file get messed up.
It all looks fine on screen, and when I place a PDF of the INDD file and print that it works fine. So my best guess is that placed INDD files don’t keep their transparency info (including clipping masks) when printing.
I’ll put together a same file and email it to you tonight (busy day ahead) so you can see what I’m talking about.
For the book covers that I was doing in InDesign, they were created with spot colours and then placed in InDesign. For the one book cover that printed as a straight solid colour, that was due to it not being converted to CMYK on export to the PDF, once I do this, it seems to be fine. Lesson learned.
That’s one placed InDesign file mystery put to bed.
That actually seems to be problem, not converting all spots to cmyk on export to PDF seems to be the problem.
So here’s my next question, how can you have a placed InDesign file with spot colours pdf correctly.
Sorry, this has been a massive learning curve for me. I honestly didn’t know that having spot colours in the file would be a problem.
Where I know I should have converted all my spots to cmyk on export to PDF, I could really have sworn that I had checked that box in the Ink Manager.
But there you have it, I’m an idiot.
But here’s the kicker. Even though my placed InDesign file uses a spot colour. I set the PDF – Ink Manager to Convert All Spots to CMYK.
If I change the spot colour I’m using in the InDesign file and Update the placed file. The Ink Manager check box is now filled in, so the spot colour is no longer being converted to CMYK. You HAVE to recheck that box.
Whereas I had my PDF export options already chosen, I updated the colour in the original file, relinked it and exported, thinking I using my previous settings that work all the time, but unbeknownst to me, that one check box needs to be checked again.
*Note to self – check files before ranting.
I would suggest forwarding that link to RIP manufacturers, along with a request to light a fire under their PDF Print Engine development teams. I have had a continuing correspondence with my Xerox tech analyst, who has been trying to get coherent answers from Rochester about the status of PDF Print Engine support on the DocuSP/FreeFlow platform. He shares my frustration with the slow pace of development. He can barely even get an acknowledgment that their senior engineers are working on it. It appears that they’re so concerned with wrapping a proprietary shell around the technology that any development is glacially slow.
Spot Colors and Flattening:
Example: Place a Logo into InDesign over a spot color, use Effects to create a Drop Shadow. Next, Export a PDF (1.3) with the spot inks. You send the PDF to your commercial printer.
They quoted the job as 4 color process, not 16 PMS inks :) so they convert the spot to process, but the Drop Shadow disappears.
Solution: Convert to process before creating a PDF, or use Unflattened PDF’s (1.4).
Another example why we find the PDF Print Engine to be a better choice than a PostScript workflow.
JW
Wouldn’t it be easier to have the option to “Always Convert Spot Colours to Process” in the Ink Manager, or some sort of document preference?
There is no way I would’ve known that I needed to recheck that box in the Ink Manager. I was under the impression that once I have my PDF setting saved it would always be like that, but not so, new spot colours causes the check box be a filled box.
Hmmm… I wonder how exactly does the PDF Print Engine work. After all, it might as well do a transparency flattening at the end of the process; if so, this discussion would be much pointless.
Most times ?from a designer point of view? you DON’T want the printer to alter or modify your design ?exception made for typos or such.
If the PDF Print Engine ?as we could suspect? really ends up flattening transparency, then the whole point is: would you usually need to preserve it until the final slaughter on the RIP? I think many times, you don’t.
Could it be that Adobe want us to buy that new technology ?which I think is essentially right, don’t get me wrong? and create an urge to make that transition faster when it is really no such a big need?
After all, is PDF-X1a or X3 really so problematic when printing?
J. Esteban,
There is no reason for the APPE to flatten transparency. That’s only necessary if you have to convert to PostScript.
As to whether flattening transparency with PDF/X-1a or X3 can be problematic, spend a little time on the Adobe User to User Forums, and count the number of transparency-flattening related issues brought up (thick type, missing drop shadows, stitching).
However, if it’s working for you, enjoy!
Steve, I agree with you, but with one technical correction: Ultimately the APPE does actually flatten the transparency. After all, there are no transparent laser dots on the platesetter or whatever you’re imaging on.
Similarly, all RIPs turn all our wonderful vector artwork into very high-res bitmapped images. That’s what a “raster image processor” does, after all. It converts everything into imagesetter/platesetter dots.
So, just as it makes sense to keep things as vector artwork until you print (and let the RIP convert it at the last moment before imaging), it makes sense to do the same thing for transparency… and often for color management, and other stuff.
Yes, you’re correct of course about that. Sending PDF through to the end is much “smarter” than sending PostScript. Dov Isaacs, Principal Adobe scientist who is the godfather of APPE, likes to say that using the APPE maintains the artwork at the “highest level of abstraction” until rasterization instead of dumbing it down like PostScript does.
David, I actually think that the more technically you’re speaking, the more it’s incorrect to say that the APPE flattens transparency…unless you’re conflating two very different ideas or processes.
“Flattening” in this context refers to the conversion of transparent PDF objects into the flat, two dimensional, non-transparent Postscript model.
The PDF print engine doesn’t flatten the transparency in a PDF in order to calculate the raster data for a separation plate. It calculates the separation rasters directly from the unlfattened, live transparent object data from the PDF file.
There’s a big technical difference between this process and any other process that requires transparent object data to be flattened first into a Postscript model at some point in the workflow, even if it’s immediately prior to the generation of separations.
David: “Ultimately the APPE does actually flatten the transparency. After all, there are no transparent laser dots on the platesetter or whatever you?re imaging on.”
I’d say that the laser dots on the platesetter are *neither* “transparent” nor “opaque” — and that hence no “flattening” takes place in any ultimate sense at that end of the raster imaging process. The concepts “transparent” and “opaque” simply don’t apply in this domain — just like, say, a *thought* can’t be “colored,” but that doesn’t mean you can say it’s “colorless”.
Hey, I’ll take you both (Tim and Klaus) on in this or any other fight, one hand behind my back, blindfolded, and bare-fisted, out in the parking lot. But not today. Today, I have a small headache, and I really should sit down.
In the meantime, let’s just say it’s semantic quibbling, involving what the meaning of “is” is. (Actually, it’s what the meaning of “flattening” is.) The important thing is that it’s happening in-RIP instead of in a blind pre-process, so it’s going to work better. Period.
David, let me know when you get over your headache…I’ll still flatten you…semantically…you and your stylish blindfold… ;^)
plz send me extra information
thank
tel:+989149096978