Claudia McCue

Before you freak out, it’s not a common circumstance, nor is it a showstopper. Just thought you might like to know. Here’s the equation:

Place a layered PSD as an anchored object within a header or footer row in a multi-page threaded table, and then attempt to print to a PostScript printer. The job starts to print, then displays the above error dialog: “The Adobe Print Engine has failed to output your data due to an unknown problem.” Continue Reading »

Occasionally, when I answer tech support questions for attendees in classes or seminars, they thank me twice: once, for solving their questions, and again for saving them from dealing with Adobe tech support. Citing long holds, repeated handoffs to other support personnel, undecipherable accents, and unsatisfactory results, they’d ask, “Can we just call you instead?” I caution them that I can’t answer everything, but tell them I’ll try. Because of my long loyalty to Adobe, I apologize for their experience, telling them that I’m sure their experience is rare and that they shouldn’t hold it against Adobe.

But the increasing frequency of such complaints has left me wondering if declining tech support quality could be a trend at the Big Red A. Since I’m quite fond of Adobe, that’s distressing.

Continue Reading »

The Smart Text Reflow feature in InDesign is quite useful: if you add more text to a multi-page story, new pages are generated at the end of the story, avoiding overset text. It’s on by default: you can turn it off, or you can modify the preferences so that Smart Text Reflow applies not just to master text frames. It can be a runaway train, but usually it’s an asset.

However, I’ve discovered an odd (and rare) bug with Smart Text Reflow. You’ll only encounter it under specific circumstances, if you perform the steps in a particular order. It happened to me while teaching an InDesign class, and it took some time to figure out that Smart Text Reflow was the culprit. I thought I’d spare you the aggravation by describing the problem so you can avoid it: Continue Reading »

I’m an advocate of neatly-trimmed filenames — I use InterCapsAsVisualSeparators  or underscores_as_physical_separators. You should avoid using the special characters that are often used to represent ?/@#$*\&! profanity, not to be polite, but because some of these characters have special meaning to operating systems.

For example, a period at the start of a filename drives it to the top of a directory list on a Mac, but if that file is uploaded to a Unix server, it becomes invisible. Whee! We’re no longer limited to the old eight-dot-three strictures (eight alphanumeric characters, then a period, followed by the three-letter extension, for you young folks out there), but excessively long filenames are truncated by some systems, which could munge your file linking in an InDesign file. (Where’s that file named “Rhododendrons in the mountains in Spring New Final Image.psd”? Oh, it’s now named “Rhododendrons in the mo~.psd”. No wonder InDesign is confused.)

For the most part, long names and special characters become an issue only when jumping platforms, but I discovered today that Illustrator CS3 and CS4 won’t allow you to place a file with a forward slash (/) in the filename. It allows you to select the file, but when you click to “deposit” it in the Illustrator file, nothing happens: there’s no error message — it just sort of turns up its nose, digitally speaking. (It has no objection to a file with a backslash (\) in the name, however.)

Oddly, InDesign and QuarkXPress don’t care; just Illustrator.

This won’t affect you, however, because you’re conscientious about your file naming, aren’t you?

It’s worth highlighting David Baldaro’s latest comment on the original post. There have been some discoveries.

“Folks, I’ve been chatting with the R&D team on this issue. For all the details check out my blog, http://david.baldaro.me.uk/2009/03/xmpie-and-the-missing-plug-in-issue/”

Here’s an excerpt from David’s blog:

[From one of the XMPie R&D folks]   “The problem that is experienced is a result of XMPie adding properties to certain components of the document. For example – A spread gets the property of whether it has a visibility ADOR or not. A box gets the property of whether it has text length handling (auto flow, copy fitting) and if so In what way.”

“The way this is implemented is by using the only technology available for this by Adobe which as a by-product forces that the properties are added to the document whether you actually place valid values or not (meaning – whether you set them or not).  If they are not set to specific values they simply get null values – but still the properties are there.  Since the properties are there taking the document and opening it in another InDesign installation provides a warning that there is no support for these properties – i.e. the “missing plug-in” warning.”

David continues:
“So, the answer here is not straight forward, and XMPie is talking to Adobe about this matter it would seem. Gal goes on to mention that they have seen this issue replicated in several other Adobe Plug-ins that make changes to the document in the same way; so it would seem that this is not solely an XMPie issue.

The best way to overcome this?
* You could always install the XMPie plug-in I guess; free-of-charge and fully functional from www.xmpie.com.
* If you are the creator of the document then disabling or removing the XMPie Plug-in; before resaving the document should work.
* Exporting the document to an INX or IDML file will also do it’s best to remove any conflicting tags.”

====================================

My thanks to David for doing all this detective work. Clearly, the problem is not solely an XMPie issue: it seems that some of the normal interactions required for a plug-in may force the plug-in to modify the document in ways that permanently alter the underpinnings.

Have you encountered similar circumstances with a plug-in? We’d like to hear about it!

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 »