The answer is yes, BUT. There are two gotchas that I know of, built-in trade-offs: High resolutions photos get dumbed down to medium-res JPEGs, and all interactivity is stripped out. It makes no difference if the images or stories with hyperlinked text are editable to the InCopy user or not. Why does Adobe hobble InCopy output? I really don’t know, it was a decision their engineers made long ago. I wonder if anyone over there remembers, actually.

Images in InCopy PDFs

Vector graphics (Illustrator or Corel Draw-like) are fine, as is type, since that’s also vector. InCopy exports those elements as paths with fills, which are by nature resolution independent. That is, they’ll print at the highest resolution your device can manage; and if you’re looking at them on a monitor, the preview will appear as sharp as the type, even as you zoom in to 4,000 percent.

It’s only the raster images (scans, photographs, Photoshop art) that InCopy modifies on output. And not just outputting to PDFs, but also when you print to the office printer.

You can see the what InCopy does to your images quite easily, if you have Acrobat Pro. Open up the PDF in Acrobat and find the Output Preview tool/dialog box, part of the Print Production tool set. Select the Object Inspector preview in the dialog box and click anywhere on the page. The dialog box tells you all sorts of information about the page objects where you clicked, including resolutions.

Take this simple one-page layout for example. The large image of the shop’s storefront was a Photoshop file that had an effective resolution (after scaling in InDesign) of 532 ppi. That’s what the Links panel showed in both InDesign and InCopy. But after InCopy had its way with it during output, the picture is now 150 ppi. (click these two images to enlarge, then click the Back button to return).

In contrast, if I click on the large drop cap “H” (which is not art, it’s a character from a font) or on the vector drawing of the fall leaves, the readout just gives me path and fill information, resolution does not apply.

Now, 150 ppi is not bad, I mean, it’s twice the resolution of most web site images … it’s medium resolution. Your PDFs might look just fine with medium-res photos. But you know, it would be nice if Adobe mentioned this in the Help file somewhere.

Goodbye, Hyperlinks

The other gotcha is that InCopy strips out any interactivity that might be there, like buttons or links or page transitions that the InDesign user may have included. I don’t know why it can’t even support simple text hyperlinks, like the one in this caption that says “hot chocolate” (and links to the chocolate company’s web site).

I added the hyperlink to the text in InCopy, as you can see in the first screen shot, but when it’s opened in Reader or Acrobat (second screen shot), the formatting remains but it’s not longer a hyperlink. I’d have to re-do it in Acrobat.

If InDesign can include hyperlinks when it exports a PDF for print (which makes no sense, but it does save making a trip to a different dialog box, as David ranted about recently), why can’t InCopy? Another question for the ages.

When you run into an issue where users on one platform can check out stories from a layout or assignment, but users on the other platform cannot, look at the filenames to make sure they’re not the root of the problem. (After making sure everyone’s server permissions are correct, of course.)

Recently, a user was describing this exact same situation in a thread on the Adobe InCopy forums on Adobe’s web site. Actually, what he reported was that the links to some of an assignment’s stories were being reported as “Missing” (a red stop sign) by the Windows InCopy users, but were fine for the Mac InDesign users—even though all files were stored on a central file server. Weird, huh?

Early on, one of the people trying to help him out asked him, “Are there any non-Lower-ASCII characters in any of the filenames? Accented characters can get remapped on servers, so that’s something to watch out for.” The user said no, the InDesign users employ a strict naming convention for assignments and layouts, always avoiding accented characters. After a few more bouts of “try this” and “try that,” all unsuccessful, he posted a screen shot of his InCopy’s Links panel showing the missing story links. I don’t think he’d mind if I showed some of it here:

Can you spot the problem? The two missing stories have accented characters in their filenames, right near the ends of the names. When the user unlinked those stories from the layout, and re-exported them with new filenames (sans accents), InCopy had no problem finding the filenames and the “missing link” issue was solved.

How Did It Happen?

The InDesign users, while careful not to name assignments or layouts with accented characters, had no control over how InDesign automatically named stories when using one of the InCopy > Export All Stories to Assignment commands. As you know, in that situation, InDesign uses the name of the layout as a prefix, inserts a hyphen, and appends the first word or two from each text frame to keep the filenames unique. (If the text frame is empty, it adds “Text 1″ “Text 2″ and so on.)

In this case, some of the text frames the Mac-based InDesign users were exporting to InCopy format had a first or second word that contained an accented character, and that character in the filename was getting remapped on the Windows server.

It would be nice if InDesign would strip out high-ASCII characters when using them as filenames, but it doesn’t.

Adobe’s Advice

It was heartening to see a couple Adobe engineers jump into the forum discussion to help out, especially since the forums are expressly not supposed to be an official resource for tech support. One helpful Adobe guy offered some insight into exactly how InDesign autonames InCopy files as it exports text frames, even though I think he got his file types confused at one point (so I’m editing this quote to correct it):

InDesign automatically names .icml files that it creates in the Contents folder while generating InCopy Assignment files (.icma), using this formula:

Trim to 26 characters ([.indd file name] + [story text]) + .icml

If the INDD filename is 26 characters or greater, then the story text never contributes to the names of the .icml, and the subsequent .icml files in the same Assignment file will be clipped and incremented.

In other words, if the INDD filename is 26 characters (“AbcdefGhijkLmnopQRstuvwxyz.indd”) or more, InDesign doesn’t grab a word or two from the text frame for filenames. It just uses the layout name, like so

AbcdefGhijkLmnopQRstuvwxyz.icml
AbcdefGhijkLmnopQRstuvwx-1.icml
AbcdefGhijkLmnopQRstuvwx-2.icml
[...]
AbcdefGhijkLmnopQRstuvw-10.indd

Thus, to avoid the “accidental accents” problem entirely, you could rename the layout so it has at least 26 characters before you start exporting stories to InCopy format.

Otherwise, you could comb through the layout and either remove (perhaps Convert to Note) any first words in frames that have unusual characters before exporting all stories, or export each problem child frame individually to InCopy format (InCopy > Export > Selection), in which case you get a chance to name the ICML file yourself. Do either one of these actions, and then you can use the Export All Stories commands as before, since it won’t re-export frames that are already linked to external ICML files.

If you see a scary red stop sign icon (it’s a hexagon, I checked) on a workflow story, instead of the usual globe or pencil, it means the story’s link is missing — neither InDesign nor InCopy can find the external InCopy file that is linked to the text frame. Which means that no one can check out or edit the story.

What happened? Someone (I’m not saying it was you) moved or renamed one of the interrelated files that are part of the whole InCopy/InDesign workflow, or saved it in the wrong location in the first place. Some real world examples I’ve heard include:

• Designer exported a frame to InCopy format and inadvertently saved it to their own computer instead of to project folder on the server (so to the designer, everything’s fine, but to anyone else opening the layout or assignment off the server, there’s a missing file);
• Editor or designer wanted to bring work home, so they copied the layout or assignment to their USB Flash drive but not the folder full of linked InCopy files (please don’t ever do this, not even if you do remember to copy the InCopy files, use e-mail-based assignments instead)
• Production manager or IT tried to “clean up” the server, and while working in the Finder or Windows Explorer they inadvertently moved or renamed a linked file

Luckily there are a couple ways to easily fix the problem, and one “last resort” fix.

Whoops, Sorry Sir, I’ll Put it Back

If you know where the linked InCopy file is (or can find it with your computer’s Find command) just move it back to where InDesign or InCopy thinks it should be, and the problem goes away.

You can learn the location and filename that ID/IC is looking for with the help of the Links panel, available from the Window menu in both InDesign and InCopy. Open the Links panel and look for the entry with the stop sign icon.

If there’s more than one, click inside the story’s text so that ID or IC highlights that story’s link in the Links panel, the same behavior as the Assignments panel.

Now double-click the missing file’s entry to open the Link Information dialog box, and then look at the Location field at the bottom.

It’s kind of hard to read, but the Location field reports the file’s “Last Seen Location,” the path and filename that IC/ID is pining for. Here’s a zoomed-in view:

Switch to the Finder or Explorer, find the linked file, and move it to that location (renaming it to match the remembered filename, if necessary). Switch back to the program, and both IC and ID should immediately remove the Missing Link icon. Now you can check it out and proceed as usual.

I Meant to Do That

What if you moved or renamed the linked file on purpose, and want to keep it that way? For example, let’s say that to fix an InCopy story which was exported to the wrong location (see the first bullet point above), you went to the Finder/Explorer and moved the INCX file to the correct location.

Now you just need to tell InDesign what you did. With the missing link selected in the Links panel, choose Relink from the Links panel menu (or, if you still have the Link Information dialog box open, click the Relink button to the right of the Location field). The Relink dialog box opens, allowing you to navigate to the new location of the file. Select it and click the Open button.

If you’ve renamed the link, you’ll get an “Are you sure?” alert, a failsafe in case you selected the wrong INCX file. Just click Yes, and InDesign shrugs its shoulder, links to the story to the “new” INCX file, and the stop sign goes away. If you look at the Location field in Link Information, you’ll see it’s now updated with the new path and filename.

Only InDesign is able to relink stories to a layout (and thus, to an assignment). Even though InCopy has a Relink command, it only works with standalone InCopy files, at all other times it’s dimmed.  But as soon as the designer saves the layout file and updates the assignment, InCopy users can choose File > Update Design to see that the link is fixed.

By the way, InDesign CS4′s revamped Links panel has a wonderful new feature called Relink to Folder.

Relink to Folder allows you to quickly fix a whole bunch of missing links that are missing only because someone moved or renamed the folder itself (the one that contains the missing files), or because you moved all the linked files to an existing folder with other files. It doesn’t help if you’ve renamed the files, though.

To use the feature, shift-click all your missing links in the Links panel, choose Relink to Folder, and in the resulting dialog box, select the folder containing the linked files. Click the Choose button, and InDesign reestablishes links to all the missing files it finds in that folder.

When you’re done, remember to save the changes to the InDesign file, updating any affected assignments if necessary, so that the InCopy users working on the layout can choose Update Design and see healthy links again.

In Case of Emergency, Unlink

If the linked INCX file is nowhere to be found, the only solution is to unlink the story in InDesign (not possible in InCopy), and then re-export the story to InCopy format.

To unlink a text frame from its external INCX file, open the layout in InDesign, select the story’s entry in the Assignments panel,  and click the Trashcan button at the bottom of the panel.

Doing so doesn’t delete the story in the layout (dumb icon, in my opinion), it just breaks its link to the external INCX file. If clicking Trashcan icons makes you nervous, you could use the Unlink command instead, found in both the Assignments and the Links panel menus.

After you unlink a story, the text remains in the layout, intact and unchanged, within a “normal” InDesign text frame (no workflow icon). Now just export the story to InCopy format again, however you normally do it, and it’s once more available and ready for checking out.

Now, how could a story be out of date (the triangle icon) if you’re editing it (the pencil icon)? No one has a more up to date version of the story than you, right? And no one else could have saved changes to the story while you were working on it. So the icon makes no sense. Yet there it is, staring at you. What gives?

After having been on the receiving end of this question one too many times, I sent it in to my friends on the InCopy workflow team at Adobe. Hallelujah, they weren’t laid off, and answered me promptly with one easily reproducible reason the icon might appear. But before I explain it, it would help if we first reviewed the normal workflow statuses.

A story’s status starts out as “Available,” signified by the globe and paper icon.

When you check it out, its status changes to “Editing” (a pencil icon) for you:

And “In Use By” (pencil with a slash through it) for anyone else on your team working on the same document:

As you edit the checked-out story, nothing changes, icon- or status-wise, for anyone. It’s only when you save changes to the story  (File > Save Content in InCopy, or File > Save in InDesign, if you’ve checked it out in ID) that the story’s status changes. Saving changes to the contents of a file also changes the file’s last modification date and time — aka its timestamp — as is true for any file on a computer.

On your end, the story you’re editing should still show a pencil icon and nothing else. After all, you can see your changes that you just saved, so it’s not out of date.

For anyone else working on the document, your story’s status changes to “In Use By and Out of Date,” usually within a few seconds of your save action, depending on how fast the network is.

How does it know when the story is out of date? During its periodic checking of the linked files on the server, your colleague’s copy of InCopy or InDesign detected a new timestamp for the story, newer than when they first opened the layout or assignment. When the timestamps don’t match, the workflow adds the yellow triangle icon to the story, cautioning users that what they’re seeing is not the latest version. They could ignore it, or they could choose to Update Content if they want to see those changes you’ve just saved, as I’ve done below.

So, Update Content means, “Get me the current contents of the InCopy file linked to this frame.” Or if you want to get technical about it, “Synch the timestamp of the file on the server to my preview of it.”

The Mystery Icon Revealed

Now that we’re all experts on InCopy status icons, let’s take another look at this bad boy:

You know that the out of date icon means that your preview of the InCopy story does not match the timestamp of the story on the server. But you’re in control of the story, you’re editing it. What you see as you edit should always be up to date. Assuming the server and our computer’s clocks are synched, how could this happen?

Here’s what Adobe said: It can happen because you saved changes, then chose Edit > Undo, bringing the preview to a state prior to the Save. You may not even be aware that’s what you did, but chances are likely that’s the culprit. Try it for yourself!

Some people think that choosing Save “clears the decks,” and so the Undo command only applies to things you did after you saved. That used to be true, but not for most design and editorial programs these days.

After you check out a story in InDesign or InCopy, every one of the edits you make to the file is noted behind the scenes. Choosing Save Content (or Save in InDesign) writes those changes to the linked story on the server, but it doesn’t erase the history of your changes during the active session. You can still Undo your edits, even if you were saving every five minutes, all the way back to the state the file was in when you first checked it out.

It’s only when you check a story back in (note the “Can’t Undo” alert) or close the file (clicking Yes when it offers to check the stories in) that the Undo history gets erased. Your editing history also gets erased when you choose Save As to an InDesign layout or a standalone InCopy file.

As you know, choosing Save also changes the timestamp of the file on the server. As soon as you Undo to a state before the most recent Save, your preview is of a state prior to the one on the server. The timestamps are out of synch, and you get the yellow triangle icon on the story — even if you’re currently editing it.

Fixing It

It’s not something to be overly concerned about, actually. As soon you once again choose Save, the out of date icon goes away. Where people get in trouble, though, is when the try to update the story — out of force of habit, I’m thinking, in reaction to seeing the Out of Date yellow triangle. Choosing Update Content is fine for stories that are out of date and Available or In Use By someone else, but not for stories you’re editing.

For example, let’s say you’re working on a story that’s overset, looking for something to cut. You spot a not-totally-necessary subhead and delete it. Then you save your changes with File > Save Content, and look for something else to cut.

If you change your mind — Oh, let’s keep that subhead in, find something else to cut — and choose Undo, the subhead reappears as expected. But now the story carries the Editing and Out of Date icons, because you’re at a state prior to the most recent save.

If you choose Update Content, InCopy or InDesign will obligingly replace what you see in the frame with what’s on the server; which, if you haven’t been paying close attention, could be quite different than what you were looking at. What’s on the server is what you last saved — in this simple example, the story without the subhead. Imagine if you had been doing some heavy editing after your Undo-before-the-Save, and an hour later noticed hey, why’s the triangle here … guess I’ll Update Content … yikes! All your edits would get wiped out as soon as you chose Update Content.

Luckily, Update Content is also undoable.

So when you see the Editing and Out of Date icon, what should you do? Simply choose File > Save Content (or in InDesign, File > Save).  Your most recent edits are saved to the file on the server, and the Out of Date icon disappears from the story. Nothing changes on screen.

It can get confusing, I know. The basic thing to keep in mind when you’re editing a story is this: Do you like what you see in front of you? If yes, choose Save. If not, choose Undo, as many times as necessary to get back to your starting point. If you’re not sure, keep the file open and checked out to yourself while you mull it over.

But very seldom, if ever, should you choose Update Content for a story you’re currently editing.

Chris, a production manager at a catalog company, sent me an e-mail. He said that his company’s art department uses InDesign CS3 to put together their catalogs, relying heavily on Meadows Publishing Solution’s AutoPrice plug-in and Virginia System’s Sonar IndexPro. Chris really wants to move everyone to the InDesign/InCopy workflow, but during testing, discovered this:

I export stories (copy blocks) in InDesign for editing in InCopy on the Windows machine. I open up the same document in InCopy (windows) to test, edit some copy, save, check in, close.

Now, open this same document again in InDesign (Mac), copy updates needed, update the copy, but wait! All of the third party markers are gone! Everything that was tagged, or marked for the index, and all the pricing tags are gone.

I’ve found out when the InCopy document is saved, this is when this happens. It strips out all third party invisible text, placeholders, etc.

Painful! But the fact is that while InCopy is very much related to InDesign, and shares a lot of its code, it is a different program with its own plug-ins folder. If InCopy doesn’t support whatever the InDesign plug-in does, you’ll need to purchase the plug-in in “matching sets,” one for the InDesign users and an InCopy version of it for the editors.

However, there are a number of InDesign plug-ins that simply don’t have an InCopy version, for various reasons.

Probably the most common reason is that the basic InCopy file format, the .incx file, is a bare-bones sort of format (based on XML) and so doesn’t support whatever the plugin expects will be available in an .indd file format. Remember, when you’re using InCopy you’re never really editing the layout–the .indd file–you’re editing the bare-bones .incx files “through the window” of the layout.

In fact InCopy doesn’t have support for some text-related things that even InDesign supports internally … for example, you can’t make text hyperlinked in IC. You can’t insert index markers. And so on. (But at least it doesn’t strip out ID-created index markers and hyperlinks when the InCopy story is saved.)

Chris continued,

I’ve talked to both plugin companies about this. One thinks this is a bug issue on Adobe’s end, the other is trying to work out something to stop this from happening.

He’s doing the right thing. If your InDesign workflow relies on third-party plug-ins, you definitely need to check with the plug-in developers to see if they have an InCopy version, or at least if they know if using InCopy will harm the plug-in’s functionality as stories are edited in IC. There are many ID plug-ins that work perfectly fine with IC… unfortunately it sounds like these two, AutoPrice and Sonar Bookends IndexPro, don’t fall into that category.

But, there might be hope. Here’s what I suggested to Chris: Find the InDesign plug-ins folder (it’s inside the InDesign program folder on your hard drive), and look inside it for the subfolder containing the third-party plug-in in question. Copy that subfolder to the Clipboard, and then paste it into InCopy’s plug-ins folder, which is inside the InCopy application folder. (Of course this will only work if both programs are on the same platform, Mac to Mac or Windows to Windows.) Then restart InCopy and see what happens.

I’ve been pleasantly surprised on more than a couple occasions that it solved the problem! Often, InDesign plug-in and script developers don’t even think about InCopy–it’s not on their radar–and so don’t bother testing it during development. But if the plug-in relies on the code that’s shared between the two programs, it can’t tell which program it’s running in.

If you find it works, or almost works, be sure to let the developer know! First, of course, because you’ll need buy licenses for your InCopy machines, and second, it’s always good news to hear your product works in other applications, or just needs a little tweak to open up a whole new market for them. Tell them to trumpet the news on their home page, add it as a line item in their online store, and so on.

Of course if it doesn’t work, by all means contact the developer anyway, as Chris is doing. The more inquiries they get from potential customers, the better the chances they’ll spend some serious development time on an InCopy-compatible version.

The Alert box they’re referring to is this one:

(Now, if you’ve been using the workflow for a while, don’t jump to conclusions about the frustrated users who ask about that message. Don’t you remember how confusing the whole system appeared to you at the start? We were all beginners at some point!)

Frustrated users, the simple explanation is this: The layout (.indd) or assignment (.inca) you’re opening in InCopy cannot find the external InCopy stories (.incx) that are supposed to be linked to the file — they’re missing, or they were never created in the first place. (You’ll be able to *see* the document’s stories in the one view you’re left with, Layout, but not edit them.)

Since Galley View and Story View only show the content of linked InCopy stories, there is no reason for those views to be available.

Actually, I’m not sure why Adobe’s InCopy team made that decision — to completely remove the views in the absence of linked stories, and to put up that alert. It just freaks people out. Why not keep the views available, but leave them devoid of content? Instead of an alert, InCopy could add a line of static text to the top of each view that said “There are no InCopy stories in this document.”

Identifying the Cause and Fixing It

The root of the problem is this: Either the InDesign user neglected to export stories from the InDesign layout to InCopy format (a required step for the workflow); or she did, but those exported .incx files are not where your document expects them to be (they’re “Missing”).

Unfortunately the Alert doesn’t tell you which of these situations is the cause. But you can find out for yourself. Just click the OK button in the Alert so that the file opens in Layout view.

Now open your Assignments panel, part of the default set of panels on the right side of the screen. The Assignments panel lists all editable stories — the linked InCopy files — in the document you have open, and their statuses (available, being edited by someone else, out-of date, and so on).

In a “healthy” file with editable stories that the document can find, the Assignments panel should look similar to this:

Those entries with the blue globe-and-paper icons? Each one represents a linked InCopy file in the document you have open in InCopy.

In contrast, the Assignments panel of a InDesign file with no linked InCopy stories at all would look like this (the arrow next to Unassigned InCopy Content is grayed out because there’s nothing to reveal):

The lack of entries here tells me that I’ve opened an InDesign layout (.indd) that hasn’t been prepared for the InCopy/InDesign workflow yet. It’s actually the default state of all the layouts at your company — without preparation, InDesign files are read-only to InCopy users. Which can be quite handy, since it means that with InCopy, you can open any InDesign file you can get to, even ones from last year (and from there, print them out, export them to PDF, or select text to copy and paste elsewhere). It’s an “InDesign Reader” similar to how Adobe Reader can open any PDF file.

But if you were expecting to be able to edit this file in InCopy, then it’s not so handy! The bitter truth is that stories can only be made editable for InCopy from within InDesign — it’s the only program with an Export to InCopy command. So go back to your designer and ask them to prep the file for you. If they don’t know how, have them open their InDesign Help file (from their Help menu) and read the section called “Sharing content between InCopy and InDesign.”

By the way, it’s also possible to open an assignment file (.inca) in InCopy that has no stories. This would be the case if the designer created an assignment in InDesign’s Assignments panel but forgot to add InCopy stories to it, or hasn’t had a chance to yet.

Missing InCopy Files

As I said earlier, you’ll also get the “Galley and Story View are Not Available” alert if the linked InCopy files do exist, but InCopy can’t find them. In that case, your Assignments panel will look like this:

The stories are listed, but the red stop sign icon tells you that InCopy can’t find them. It looks for the linked .incx files with the same name and in the same location — the same folder path — that the designer saved them to when he first exported them from the layout.

So, one cause might be that someone used the Finder or Windows Explorer to manually move the folder of .incx files to a different location, or they renamed them. (It’s okay to rename the stories by editing their names in Assignment panel, but not anywhere else.)

The more common reason, though, is that you (the InCopy user) moved the layout or assignment file from its original location to a different one, like from the server to your desktop, or from the designer’s computer to the server, or to your own. None of that is kosher in the workflow. Unless you’re using CS3′s remote workflow (e-mailed assignment packages), all assignments and exported .incx files need to be on a central file server, and everyone opens the files directly from there. If you’re using a layout-based workflow, the .indd file needs to be on the server too.

There are ways for either the InDesign or InCopy user to fix missing stories — to correct the path information stored in the layout or assignment — but that’s for another (future) post, as it’s a little complicated. Better to just manage the workflow files correctly in the first place!

You Might Find This Helpful

If you’re a newbie at this whole InCopy/InDesign workflow stuff, and you’ve encountered the “No InCopy Stories” alert and wondered why, now you know (she hopes).

But I would bet that you’d feel a LOT more comfortable with the process if you read the paper I wrote for Adobe’s InCopy marketing team, “Collaborative Editorial Workflow with InDesign CS3 and InCopy CS3.” I made sure to include lots of diagrams, screen shots and step-by-steps, so new users could gain an essential understanding of how the files work together — what goes where and who opens what.

You can download the 16-page PDF from the InCopy product page on Adobe’s web site, or you can click this link to download it directly (5 MB — all those screen shots).