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.

Q: Can you only create packages in InDesign?

A: I know you’re referring to e-mail-based Assignments, aka InCopy packages (INCP in CS3, or ICAP in CS4) or assignment packages; and the answer is “essentially, yes.” Only InDesign can initiate the remote workflow by creating an InCopy package “from scratch,” that is, from a regular assignment in a layout. An InCopy user can’t do this; they can’t decide on the fly, “Oh I think I’ll work on this from home, I’ll send it to myself.” However, if an InCopy user receives a package from a designer and opens it in InCopy; then she can create another package from it. She can either return it to the designer as an InDesign package, or repackage it into another InCopy package, assumably for another editor (by choosing Forward to InCopy from her Assignments panel).

Can you explain again why the remote workflow won’t work with remote designers?

Well, I suppose it can, if the remote (offsite) designer keeps the layout on their home computer, creates assignments there, and then sends out e-mail-based assignments (InCopy packages) to the editors (and they return InDesign packages back to her).  In other words, if you keep the workflow all remote, it can work.  I actually have a few clients, some with over 60 people around the country, who are putting together publications in this way.

But when people ask this, they almost always have something different in mind. They’re thinking that the designer could “bring work home” by sending a package to himself at the end of the day, or that the editors could unpack the packages on the server since they’re all on the network, or that a production manager could create an InDesign package for a subcontracted, off-site designer. None of those work.

When the editor opens the INCP file, can you change where it unzips itself – so it’s unzipped onto a shared drive?

No, that’s built-in to the system. On PCs, the INCP (or ICAP) unzips itself into the user’s My Documents > InCopy Assignments folder; on Macs, into the user’s Documents > InCopy Assignments folder. (The first time an InCopy user opens a package, the software creates the InCopy Assignments folder on its own in those locations.) The contents of the package are copied to a folder named the same as the assignment itself. So if you look at the InCopy Assignments folder, you can see a folder representing every assignment package you ever opened in InCopy. I’m not sure why you’d want to put the contents onto a shared drive automatically, but you could always move the unpacked folder to a shared drive manually.

When we tried the remote workflow, we had a problem with elements from the Master Pages randomly “migrating” onto the layout pages. This caused the layout to be edited to contain a mess of elements that was unusable for the remote editor. Have you encountered this? Is there anyway to prevent it?

Sorry, I’ve never encountered that before. The only things that should be editable in an InCopy package are the stories that the designer associated with the assignment. The packaging step itself has nothing to do with master page items, it’s more like a “copy files and zip them up” operation. So before you package, turn on View > Show Assigned Frames to help identify them in the layout, and make sure you haven’t inadvertently included master page items in the assignment you’re about to package.

How secure is Dropbox?

Dropbox, the virtual server solution I demo’d as an alternative to the remote workflow (or even as an alternative to a local server), is quite secure. All uploads/downloads are done over an encrypted (SSL) channel, and files stored on Dropbox are also encrypted. You can read more details about Dropbox security here.

What was the format of the file you put on dropbox, i.e. was it a .incp?

No, there’s no need to use InCopy packages when you and a remote user are sharing a folder via Dropbox. You just treat the folder on your hard drive as though it was a folder on a local server. In the webinar I just put the full project folder in my Dropbox folder: the InDesign layout file (INDD), the assignment files, the linked InCopy stories, the whole shebang. Remote InCopy users open the layout or assignment from their Dropbox folder and check stories in/out as usual. It’s a miracle, I tell ya! (Except: Remember that Dropbox inexplicably allows two InDesign users to open the same layout file at once. So don’t do that.)

The InCopy Notes feature seems to be glitchy. Sometimes difficult to get the new note icon to light up. Also clicking on the note icon in Layout view does not always bring up the note in the notes panel. Comments?

The Notes feature could stand some improvement, I agree.  I don’t think it’s glitchy, though, just … hmmm … guess I’d call it “high maintenance.”   First, in order to see the icon for a note in Layout view, you have to remember that it’ll be the same cap height as the text in which it was placed. So the Note icon for 6 pt. photographer’s credit line will be like a flea speck; but the Note icon for a 60 pt. headline will be huge. I seldom bother looking for these visually; just go to the Notes menu (or open the Notes panel from the Window menu) and choose Next Note. InCopy will put the text cursor next to the note and center it onscreen. You can cycle through all the notes in a document by just using the Next/Previous Note commands.

To get the Notes panel to open when you click on the icon, you have to get your cursor hovering over the top half of the Notes icon (the downward pointing triangle), so you might need to zoom in first to see where that is. When it’s hovering in the right spot, the cursor changes to a pointing finger. Now you can click and the Notes panel will open. See? High maintenance.

———

Hoo-boy! I told you they were great questions, yes? Final part 3 (with questions about master pages, conditional text, and package errors) coming up tomorrow!

Because I like and understand InDesign and have had quirky problems using Word files, I’ve come up with a new workflow that puts InCopy in the middle. Quickly: I edit in Word then later open the file in InCopy where I do all of my formatting, knowing it will be there when I place the InCopy file in InDesign.

That was pretty neat … and I know that using InCopy to “prep” Word files for InDesign is standard practice  in a lot of my client’s workflows.

Tom had a question about something, though:

I have a workspace named Newsletter, and InCopy opens in that workspace. But when I open a story from Word, all of my paragraph styles, etc., disappear and I have to take a second to reload them. I’ve tried saving the workspace with the paragraph styles open, but it doesn’t seem to matter.

As Tom discovered, paragraph styles (or any styles) that are within the panel are ignored when you create and save a workspace. Instead, the styles panels list the styles contained in the active document, regardless of which workspace you switch to. If the program is running but no documents are open, the styles panel lists the application’s default styles (usually, only [Basic Paragraph]). When you create a new blank document, the new file contains the same default styles.

So what Tom did was to add his custom Newsletter styles to InCopy’s paragraph styles panel when no documents were open, which turned them into default styles, a clever and time-saving solution.

And indeed it would work great if he were writing newsletter articles from scratch in new InCopy files. But he wasn’t doing that — he was converting existing Word docs to InCopy. And in that case, the converted file is counted as an existing file, so the paragraph styles panel only shows the styles contained in that active document — the styles that were in the Word file.Yuk!

The solution, as I replied to Tom, was to simply stop converting Word files into InCopy format. (“Doctor, it hurts when I do this with my arm.” “Stop doing that.” Ba dum-bum!)

Instead, to retain custom styles, you should import (File > Place) them into new, blank InCopy files. Remember that new InCopy files contain default styles, including any custom ones you added to the defaults. Importing a Word file will just add the Word styles (if that’s what you want) to the paragraph styles panel. Your custom styles remain intact, ready for applying to the text.

Also, as long as you remember to turn on the checkbox for Show Import Options during the import (or hold down the Shift key when clicking the Open button, which is the equivalent):

… then you’ll still get the same Word Import Options dialog box as you would with the conversion method:

At this point you could even choose the Customize Style Import option at the bottom to map Word styles to your custom InCopy styles … now you’re cookin’!

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.

So if you’re using an InDesign/InCopy CS3 workflow, and you need to get another copy of ID or IC for a new hire or to bring a new publication into the workflow, you’re a little bit stuck. (Unless you’re ready to move everyone—designers and editors—to CS4 at the same time.) That’s why one of the most frequent questions I’ve been getting lately is, “Can InDesign CS4 work with InCopy CS3?” while the second-most frequent one is, “Can InDesign CS3 work with InCopy CS4?”

The answers are “Yes” and “Yes” … but because of new file formats and extensions, you might have to modify the way you work.

InDesign CS4 with InCopy CS3

In layout-based workflows, editors open InDesign layout files (INDD) and edit the workflow stories within them. Even though InDesign CS4 files have the same INDD file extension as CS3, InCopy CS3 cannot open InDesign CS4 layout files. If you try, you’ll get an error:

The only way to allow InCopy CS3-using editors to continue working with CS4-using designers is to provide them with Assignment files instead of having them work directly on the layout.

Even if you’re already using an Assignment-based workflow (editors open INCA files instead of the actual INDD layout), InDesign CS4 users will need to pay attention, as Assignment files have changed file extensions and formats in CS4.

You must be careful to make assignments and their stories compatible with CS3. Otherwise, they’re created and exported in the new CS4 formats—ICMA (assignments) and ICML (stories)—which InCopy CS3 cannot open. (Adobe changed the file formats to make them more accessible to XML editors outside of the programs … a topic for another post.)

You make assignments compatible with CS3 when you create them, by choosing that option in the New Assignment panel in InDesign CS4:

If you had selected frames in the CS4 layout file at the same time you created the new assignment, the external InCopy files that InDesign CS4 exports and includes in the assignment will also be compatible with InCopy CS3. That is, InDesign will export them with an INCX (InCopy CS3) extension instead of ICML (InCopy CS4). Otherwise, creating “Optimized for CS4″ assignments automatically exports stories to ICML format.

If, on the other hand, you export stories as a separate step (dragging them from Unassigned InCopy Content to the Assignment name in the panel afterwards), when you export them you need to make sure to choose the InCopy CS3 format in the Export to InCopy dialog box:

So, let’s say you have just one editor who’s working on a publication. Assignments, which help you split up a large publication into editor-specific layout files, don’t make much sense in that workflow. To keep things simple, all you need to do is to create a single assignment that is the entire layout. You could choose Edit > InCopy > Add All Stories to Assignment > New, for example, being sure to specify Compatible with CS3 in the New Assignment dialog box as shown above. Tell your editor to open the INCA file instead of the INDD file, and you’re good to go.

In fact, even if you do have two or five editors working on the same publication, you could still create a single assignment that is the entire layout and have them work on it concurrently. It’s a little-known fact that multiple editors can open the same assignment (INCA or ICMA) at the same time, just as they can with INDD files. After they open it, all workflow stories within it will be accessible to them, and the usual rule of “one user per checked-out story” still applies.

By making the Assignment compatible with CS3, you can be assured that any email-based assignment packages you create can be opened by remote editors using InCopy CS3. (Yes, packages also got new file formats in CS4.)

InDesign CS3 and InCopy CS4

It’s a lot easier to work with this combination. InCopy CS4 can open InDesign CS3 layouts (INDD) and the InCopy files that InDesign CS3 exports: stories (INCX), assignments (INCA), and packages (INCP). When the InCopy CS4 user saves changes to these files, they’re saved in the same format they were opened in automatically, without them having to choose any specific format. That means that other InCopy CS3 users and InDesign CS3 users on the team should have no issues working on files that the InCopy CS4 user worked on.

The one time that InCopy CS4 users might have to be careful is when they’re working on a stand-alone InCopy file, one that they’ve created (File > New) or one that they’ve opened directly from a publication’s “content” or “stories” folder. After editing the file, when they save their changes (or close it with unsaved changes), InCopy will put up a “Save As” dialog box. This is because it wants to save the document in the new InCopy CS4 format.

Assuming the InCopy user doesn’t want to do that, they  should be sure to choose the “InCopy CS3 Interchange” format in the dialog box before hitting the Save button:

Doing so saves the standalone document in CS3-friendly INCX format instead of the new ICML format.

Are you using a mixed-version workflow? I’d love to hear how it’s going for you … add your comment below!