Claudia McCue

CORRECTION:

I had tried a driver for the Intuos 4, which fixed the pressure issue, but lost the Touch capabilities of the tablet. I’m actually not crazy about that feature, and turn it off. But you might like it, and the 6.3.1w2 driver fixes both the pressure and touch features under Mountain Lion. I’ve corrected this post to include the later driver number, which is better for the Intuos 5 Touch.

Have I mentioned that I hate updating the OS? I used to be bleeding edge…

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

I finally replaced (well, supplemented) my oldish Wacom Graphire tablet with a Wacom Intuos 5. It’s probably overkill for the amount of retouching I do these days (sadly), but I justified it by the fact that I need to show the spiffy Erodible Brushes when I demo Photoshop CS6.

I have not plumbed the tablet controls; I simply wanted pressure and tilt ability in Photoshop and Illustrator. This is not a tablet review; it’s more of a driver review, I suppose.

I recently bit the bullet and updated to Mac OS X 10.8.2, Mountain Lion. [This is why PC users laugh at Mac users—because our Unix-based operating system versions are named after kitties.] After dreading it for so long, I wiped my drives and did clean installs; there were a few little kinks, but not as dire as I’d feared.

That is, until I cranked up the Intuos tablet for a demo 2 nights ago, and had no pressure: the option was grayed out in Photoshop and Illustrator. I was not amused. So I dug through Google and the Wacom forums for solutions: I used the Wacom driver’s “wipe out the preferences” option—no help. I uninstalled and reinstalled. Nope. I repaired permissions—grrr.

Finally, in a thread about Cintiq tablets (now I was on a quest), I came across a suggestion to install an older version of the driver. Made no sense, but I was desperate. I downloaded several of the antique drivers (current one for Intuos is 6.3.5w3). I thought what the heck and went for WacomTablet_6.3.1w2.dmg. I figured I’d try it, it would fail, and I’d work my way forward.

To my delight/relief, it did the trick—I now have pressure options in both Photoshop and Illustrator, thanks to the antique driver.

I posted in the Adobe Illustrator forum in hopes of helping other users, and thought I’d go back to the Wacom forums to do the same. I signed up, and when the confirmation email came from Wacom, I tried to confirm…and their confirmation process is broken. Sheesh. The forums are peer-to-peer, with no Wacom oversight, but since they’re available only through a portal on the company website, you’d think you could at least get in. I can read, but I can’t post.

Wacom makes good products: when I think “tablet,” I automatically think “Wacom,” and never considered another vendor’s products. But clearly they need to respond to the countless angry posts on their own forums (and others), and fix their dadgum driver. The latest one is dated just 2 weeks ago, but it doesn’t fix the problem.

This was brought to my attention by a friend at EBSCO Media.
The scenario: You’ve created a dieline in Adobe Illustrator, which uses the manually created global spot color “Dieline.” It’s set to, say, a fluorescent green for easy identification.

Place the AI file in InDesign; the dieline spot color is added to the Swatches panel. So far, so good.
Select the dieline art and choose Edit Original.
In Illustrator, change the spec for the dieline spot color to, say, red, and save the file.

Return to InDesign. Although the Links panel shows that the link is updated, the swatch appearance and the artwork appearance have not changed.

The only way to fix this is to delete the artwork, then delete the swatch and and re-import the artwork.
NOTE: Sometimes it DOES work as it should (i.e., updating the link DOES change the appearance of the artwork and swatch.) But most of the time, it doesn’t.
And…If you use a genuine PANTONE spot color from one of the sanctioned color books, it behaves as it should: change to another PANTONE color in Illustrator, and InDesign will update the swatch and the placed artwork.

Since you’d probably be using the homegrown-spot approach only when you’re creating components such as dielines and varnish plates, the actual color really isn’t important: It’s only important that a plate is generated. But it’s still odd that either InDesign ignores the change, or Illustrator doesn’t successfully communicate it. Guess it’s Just One of Those Things.

A student brought her MacBook to class and asked me to troubleshoot her new install of CS5. It would lock up when starting up, with the SBBD (Spinning Beach Ball of Death). I tried resetting preferences, to no avail. She had no third-party plug-ins, no font auto-activation — none of the common culprits. It was a clean install.

Poking through the Adobe forums, though, I came across a thread on the same problem. One poster found that deleting the SING.InDesignPlugin cured the problem.

Sure enough, that did the trick! She is now SBBD-free, and InDesign launches and runs with no problem. I didn’t have this problem on either my desktop Mac or my laptop, so I don’t know why it affects some folks but not others. But I’m passing it on in hopes it will help others.

The plug-in is here:

Applications> Adobe> InDesign CS5> Plug-Ins> Text> SING.InDesignPlugin

The forum thread is here (search for the poster “lipstickdesign”):

http://forums.adobe.com/message/3024920

If you’ve watched much science fiction, you know things always go wrong in time travel. Somebody drops a USB drive in ancient Mesopotamia, and next thing you know, dinosaurs are roaming the streets of New York.

Same thing goes for back-saving files for earlier versions of software; I always caution designers to avoid this if possible. However, I realize that designers often encounter mixed versions of applications, especially when freelancers are involved. I try to always keep files in their native habitat, in terms of software version and platform. The notion of opening up an innocent PC Illustrator CS5 file in a Mac CS4 version of Illustrator makes me twitch.

I’ve had my convictions strengthened this week; I’m working on a book in InDesign CS5, but the publisher wants the final files in InDesign CS4. I’m taking advantage of the Track Changes feature in CS5 to work with the editor, and that’s working great. However, when I export to InDesign Markup (IDML) — the only way back to CS4 — things fall apart. Paragraph formatting goes wonky. Styles based on other styles have forgotten the overrides that separated them from the parent styles, and the original formatting (mainly nested styles that I’d un-nested) bubbles back up. Like a zombie movie.

I don’t recall this happening when I back-saved from InDesign CS4 to CS3. I don’t know if I was lucky, or if back-saves have become more dangerous in the new version. The moral of the story? If you are forced to time-travel, make a PDF before you jump. Place the PDF in a separate layer in the converted file, and turn its visibility off and on, so you can check for issues.

Be careful out there. Watch for dinosaurs.

JUST TO CLARIFY: This is only true for images in which the first layer comp hides some effects (aka layer styles). If the first layer comp only involves hiding some layers, without hiding any effects, all is well. It’s not a showstopper (once you know about it) — it’s just One Of Those Things. This advice applies whether you’re using the image as button artwork, or just as static artwork in the InDesign document.

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

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