————————————————————————————————-

When you’re building complex Photoshop files, Layer Comps are a great way to store the visibility of layers that constitute versions of the image. For example, if Layers 1, 3, and 5 are Version A, Layers 2, 4, and 6 are Version B, and Layers 7, 8, and 9 are Version C, you can create three layer comps that let you access each version of the image with a single click. A Layer Comp can also store the position of layers, as well as the visibility of Layer Styles (such as drop shadows, inner glows, bevel & emboss, etc.). Layer Comps make it easy to keep track of versions while you’re experimenting, and when you want to quickly show a client those versions without trying to remember which eyeballs to turn on/off. 

Layer Comps can also be invoked by InDesign’s Object Layer Options feature, to control the visibility of layers and effect in placed PSD files; this is especially handy when you’re creating different appearances for interactive buttons. It was while creating buttons that I discovered a bug in the way InDesign handles Layer Comps. If you use Object Layer Options to manually turn layers off and on, all is well. My images had just one layer, but multiple effects (aka fx, aka Layer Styles) applied to the single layer. So I couldn’t invoke separate layers in InDesign, and had to rely on Layer Comps to control the visibility of effects that constituted each version of the button art.

I discovered that, unless you have the first Layer Comp in the Layer Comps panel list selected when you save the file out of Photoshop, you’ll never be able to reveal that first Layer Comp in InDesign. It allows you to select the Layer Comp, but ignores its settings and instead displays the layer comp that was selected when you saved the file. So you can never invoke the first layer comp in InDesign, unless it’s the selected comp when the image is saved.

As you can see in the image above, the first layer comp should just be the plain green text. But InDesign displayed the “Add Rocks” layer comp when I invoked the plain green text comp. Aaarghh (and, of course, it was late at night).

Moral of the story? If you’re relying on Layer Comps in InDesign, make sure the first layer comp in the Layer Comps panel is selected when you save the image, even if you think you won’t use it. It’ll save you the confusion and frustration that had me banging my head on the keyboard at midnight!

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.”

If it’s a single-page table (which makes header/footer rows pointless, but I digress), there’s no error. The same PSD placed in a plain old body row prints without problem, regardless of table length.

In my case, the printer is a Xerox Phaser 8400, but choosing any PostScript PPD produced the error, even if I attempted to generate PostScript using the tasteful Adobe PDF PPD. My little non-PostScript Epson inkjet printed with no problem. I could also export to PDF and print that to the Phaser successfully from Acrobat. So it’s not solely a Snow Leopard/Phaser issue.

This hit me as I was printing a handout comparing Acrobat Standard/Pro/Extended features. After narrowing down the culprit, I substituted a flattened PSD using a Photoshop path to silhouette it, and printed with no squawking.

NOTE: I suppose this marks me as a Luddite, but I never made the move to Leopard. I was reluctant to update my demo/training laptop because of early issues between Leopard and Creative Suite applications. To me, there was no compelling performance improvement, so I stuck with the old faithful cat. But when Snow Leopard was released, I thought I should catch up. I bought a Mac Pro desktop and started from scratch. With the exception of this oddball issue, it’s been fine. The new version of Suitcase runs fine, the apps behave, and all is well.

Let me know how Snow Leopard is working (or not working) for you.

———————————————–

On another note, I’m over the cute cat names. How about just using the version numbers? Ten Point Six — what’s wrong with that? It’s definite, unambiguous, solid. Not fluffy.

Or memorable monikers like “Galactica” or “Bonaventure”? Maybe famous composers: “Hey! I just loaded Mozart!”

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.

Now, it seems, there’s some confirmation of my clients’ complaints, as well as some hope that those complaints are being addressed. On the main Adobe support page, there’s a brief message from Lambert Walsh, VP of Technical services. It reads, in part:

Adobe is committed to providing the most advanced, innovative products and services in the world. Recently, however, our customers have experienced a level of service that is inconsistent with what they expect and deserve. This is unacceptable and we sincerely apologize for the inconvenience caused. We are working diligently to resolve these issues.

Lambert’s full letter is available here as a PDF.

I understand how tough it is to provide comprehensive tech support; I provide support for Photoshop, Illustrator, InDesign, Acrobat, and general printing issues for my clients and seminar attendees, and it can take some digging to solve their problems. For me, the rewards are that my client’s life now runs more smoothly, and that I often learn new things as a result.

Given the mile-long list of Adobe products, I can’t imagine the challenge involved in finding knowledgeable personnel to field the ocean of tech-support calls. From installation and activation issues to unique weird conflicts (and user proclivities), it has to be a nightmare. I don’t envy Mr. Walsh!

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:

1. Create a facing-page document.
2. On the master spread, create a placeholder graphic frame on right page.
3. Create a text frame on left page of the master, create another text frame on the right page of master, and thread the frames from left to right.
4. Go to a right-hand document page in a spread—not page 1 (say, page 3), and place an image in the placeholder graphic frame.
5. Go to the left page of the same spread, and place at least enough text to flow into both threaded text frames on the spread. Don’t hold down Shift; just allow the text to flow according to the default Smart Text Reflow action.
6. Result: Graphic frame disappears, “flushed” to the next document page after the end of text flow. Doesn’t matter if the graphic frame is above or below the text frame, or even if it touches the master page text frame. The graphic frame may or may not have text wrap applied.

This behavior does not occur if:

• You place the text before placing the graphic.
• You shift-click to Autoflow the text (even though it’s going to flow anyway).
• The graphic frame is on the left-hand page.
• You start flowing text on page 1 or any other right-hand page.

What’s happening? Apparently Smart Text Reflow completely takes over: “The text must live! All other frames, get out of the way!” Keep in mind that the circumstances are specific and rare, and you may never encounter it. (If you teach from the Classroom in a Book, step carefully in Lesson 3.)

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?

“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!

Because of the wide usage of direct-to-plate workflows, few printing companies are still outputting and manually stripping film, although I suppose it may be going on in the hinterlands. The only exception would be specialized printing processes, such as screen printing or metal etching. While registration marks and other locating marks are used on press to monitor ink alignment, those marks are usually generated by the imposition software that positions the pages for output, rather than the original page layout or illustration applications.

What color, exactly, is Registration? It’s all the inks used in the document: it’s 100% of all inks. So, in a job containing CMYK plus PMS 185, Registration would be C100-M100-Y100-K100 plus 100% PMS 185. This adds up to a whopping 500% ink coverage where Registration is used. This is not a press problem in isolated areas such as trim and registration marks, but such heavy ink coverage in larger areas would result in drying issues and other problems. And if there’s slight misregistration on press, you’ll get a bleary multicolored fringe:

This is exaggerated for dramatic effect, but it's still possible for thin fringes of color to spoil the look of the printed piece.

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

Why do I bring this up? Because twice this week I encountered files built with Registration instead of plain old Black. If there had been just one element — say, a line of text — using Registration, I would have chalked it up to mis-clicking: aiming for Black, and accidentally hitting the next color in the list. But, no: in both cases, Registration had been used for all the text in the InDesign page, as well as artwork created in Illustrator. Clearly, it was intentional. But why?

My guess is that the designer thought plain old Black just wasn’t robust enough; maybe it looked anemic on their desktop printer. And it’s true that process black ink alone in large areas can look, well, gray rather than black: that’s why we use rich black builds in large areas. Registration is not an appropriate “rich black,” however!

If your design contains large bold black text (40 pt or above), or large solid black areas, consider using a rich black build (try C40-K100). Better yet, ask your printer what they’d recommend for a rich black recipe, as well as their advice on where to use it (i.e., text size or color area dimension).

I wish the applications wouldn’t even display Registration; maybe it should be a hidden color choice, available only from a subsidiary panel menu in the Swatches and Color panels. Until then, you’ll have to police yourself: don’t click there!

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?

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.

In those long-ago days, PC designers were in the very small minority; that’s no longer the case. When I survey an audience these days, roughly 40% are PC users: the Mac monopoly on graphic arts is over. The predominant graphics programs — Adobe’s Creative Suite and QuarkXPress — are available on both platforms, PCs are often less expensive than Macs, and it’s easier to convince a corporate IT crew to let you get a PC than to bring a Mac into a Windows-only business environment.

In light of this, there’s no excuse for a printer to risk taking a file cross-platform because they either don’t own a PC, don’t have a prepress operator who knows how to use a PC, or because they think it doesn’t matter. None of those circumstances is excusable in the current marketplace.

Yet that’s what a printer recently did to a customer’s PC InDesign file. Not only did they open and resave the customer’s file on a Mac, they substituted Mac fonts for the PC fonts (not even the same fonts, for cryin’ out loud!), then returned the file to the customer. My customer can’t use the Mac PostScript fonts. Shoot, I couldn’t even use them on my Mac: they were corrupted, all weighing in at zero KB.

By the way, this is the same file that was “poisoned” by the XMPie plug-in in my earlier post. Poor file has really been through the wringer.

My advice to the customer is to have a stern conversation with the printer about file mistreatment, and to ask them if they have the capability to correctly handle PC files. If they don’t, then the customer will be forced to purchase OpenType versions of their preferred fonts. Then, at least their files will be safer regardless of sloppy and thoughtless file handling at the printer. Sheesh.

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.