Look in the Swatches panels of InDesign and Illustrator, and the Colors list in QuarkXPress, and you’ll see a mystery color named “Registration.” It’s intended for page information, registration marks, and trim marks. When we used to output film and strip it up on light tables, we used registration marks to ensure that all the inks printed in alignment. Registration is intended for use only by the application, not the user, except in rare cases.
Continue Reading »
You, of course, would never do such a thing. But you might have a friend who would, or an evil twin brother…
To resize an ad to fit in another publication, you should change the dimensions of the document, then resize and move existing content as necessary. In this case, however, the ad creator took a simpler approach, electing to just change the document dimensions. What’s wrong with that?
How Not to Resize an Ad: It looks fine, until you realize the discrepancy between the document trim and the artwork. Oops.
Ah. Don’t look at the image and text; note where the black border indicates the trim edge of the InDesign page. Yep, that’s right. If this mistake had not been caught, the ad would have printed like this:
A quick trip to Preview Mode would have warned the ad creator, who surely would have fixed the job.
(This isn’t the actual ad. It’s just my quick example of what can go wrong.)
I’m trying to think of a rational (and charitable) explanation for this: Perhaps the designer had changed the document size, and was about to massage the contents, but was suddenly abducted by aliens. I post this not because I think this is a common problem, but because we laughed so hard when we saw it. And then we trembled in fear: oh, dear — what will they send in next time?
I was raised on Macs (well, actually, I was raised on X-Acto knives, but let’s fast-forward a bit). But I learned Windows in self-defense many years ago. At first, it was a bit foreign (we’re talking Windows 3), but not painful. After all, it’s not as if Microsoft hasn’t, ah, emulated the Mac interface.
Why did I do this? So that I could handle customers’ PC files when they came into the printing plant. We had quickly learned that it wasn’t smart to try to move the files to the Mac: fonts didn’t translate, text reflowed, and things generally fell apart. It made more sense to keep the jobs in their native habitat.
Continue Reading »
A client sends their InDesign CS3 files to a printer, who makes any correx, then returns the corrected file to my client. When the client reopens the file, they receive an error message indicating that they are missing plug-in “XMPBackEnd5.pln.InDesignPlugin.” Usually, this is just a courtesy announcement; plug-ins for InDesign are supposed to be written so that their absence doesn’t mess things up for a recipient who doesn’t have the plug-in.
But in this case, it’s not so innocuous: the file opens, but my client cannot package it after they have worked on the file. The only solution is to run it through InDesign Interchange and open the INX file; this removes all desire for the missing plug-in. Then, the file behaves normally, and can be packaged successfully. Nice that there’s a workaround, but this is no way to live.
LATER NOTE: the XMPie uDirect plug-in seems to leave this residue only if personalization data is added to the file. If a clean file is simply opened, worked on and saved, there’s no problem down the line. The issues arise when personalization data is added, and then the file is passed on to someone who doesn’t have the uDirect plug-in. So it’s not universally dangerous.
I received this response from XMPie support: “Thank you for pointing us into this problem. I have sent this request to our Product Manager and I hope that this problem will be handled in future versions of XMPie.”
If you don’t know what XMPie is, it’s a powerful and nimble variable-data solution for InDesign. I’ve seen it in action, and it is very cool. But beware of this glitch until it’s fixed.
It was another one of those thoroughly snakebit jobs that go wrong at every step, but at its core is a mystery concerning how QuarkXPress treats an overprinting grayscale image in an exported PDF. “Regular” overprinting objects, such as text or boxes, display and print predictably. But grayscale images are handled differently, and this results in a misleading display in Acrobat, which leads to a surprise on press. And, as you know, “surprise” is not a good word in printing.
Here’s the timeline: Continue Reading »
I’ve just received word that my book, “Real World Print Production” (Peachpit Press, 2006) is going to be revised. I’m pleased that Peachpit is going to let me update the book for current versions of software, and it will also give me the opportunity to expand some of the other content to reflect changes and growth in print and imaging technologies.
It all sounds like such fun now; check back when I’ve been up for 18 hours pounding the keyboard or staring at a stubborn paragraph
No ETA yet; I haven’t started pounding the keyboard. But I’m hoping to have it done by early Spring.
If you’re a print service provider who’s starting to receive CS4 files for output, you might appreciate the latest revision of the venerable Printing Guide. It’s now available here.
The PDF is fully bookmarked; open the Bookmarks panel (View>Navigation Panels>Bookmarks) to reveal the extensive list of hyperlinked topics. Additionally, the Table of Contents is hyperlinked to internal content, so it’s easy to find your way around.
Designers will find lots of useful content, too. You can select a low-res or high-res version of the 139-page guide, and you’ll also find the CS3 version of the printing guide on the same page. Both offer insights into print-specific features in the Suite applications, and provide cautions and workarounds for each application.
I’m proud to say that I’m responsible for both the CS3 and CS4 revisions, starting with the CS2 version and building on its content. Consequently, some of the content is legacy, some was contributed by other revisers during the early CS3 phase, but the final versions of both are my doing. It was a labor of love, and I’m proud of the finished pieces. I hope you find the guides a valuable resource.
Given recent upheaval at Adobe (600 layoffs yesterday, including some very dear friends), I don’t know if there will be more versions of this resource. If Adobe doesn’t spearhead an update for future CS versions (assuming there will be future CS versions, and I can’t imagine there won’t be), I’ll do it myself.
My friend Randy received a customer’s InDesign CS4 file which simply refused to package all of its links. There’s an easily-overlooked option in the Links panel menu that will copy all links manually (Utilities > Copy Links To…), but even that refused to gather more than a few links.
I exported the file to InDesign Interchange (.inx), opened the .inx file in InDesign CS4, confident that would do the trick, but to no avail. So I opened the .inx file in InDesign CS3; no luck. I searched for known issues, but “failure to package links” didn’t appear anywhere. There was nothing exotic about the links — just TIFFs, EPSs, and JPEGs. Continue Reading »