Indesign CS 5.5 (bugg with clipping paths)

[Magnus]

Since we started using Indesign CS 5.5 a few weeks ago we have had some weird stuff going on with clipping paths.

The last error was when we updated the links in a document from a customer and a photoshop clipping path in a tif-file was suddenly activated and this unfortunately caused a reprint.

Have anyone else had this or a similar problem?

(we are running OSX)

 

[Al Ferrari]

"(we are running OSX)"

Which one?

 

[abccolor]

existing threads

existing threads

I am providing the links to two treads which may shed light on this topic.

Adobe Forums: InDesign - Transparency Effects not displaying in PDFs

http://printplanet.com/forums/adobe/23379-indesign-transparency-effects-not-displaying-pdfs/2

 

[RandyD]

Yes I have seen similar problems. You have to be aware when updating links and I recommend closely scrutinizing the file proofs. I've seen this happen when changing a file from a Photoshop .jpg with a clipping path to a Photoshop .tif with a clipping path. When updated to the .tif the path changed slightly. I have also had more clipping path issues when designers have used Alpha Channels to designate clipping. Not so much fun.

Usually on my own designs when possible if I'm using a graphic or photo that would be close cropped I will opt for a .tif with a clipping path with a flatness of "3" set in photoshop. Then when placed to InDesign stick with a photoshop clipping path option and select the particular clipping path in the file. You also have to select whether to include enclosed or (internal) paths if you have dropouts within our crop region.

 

[Lukas Engqvist]

Haven't used clipping paths in years. Is there any special file format? Tiff, PSD, JPG? Does it happen in InDesign? Can you see it in InDesign or is it downstream in your workflow?
I would check for double clipping paths that are near identical. Without the files can only speculate as to what is causing it. (There usually is an explanation)

We used to have issues like that in the old days of OPI…*one of the reasons we stopped using OPI. Would be great to know more specifics. (Lol followed the thread and found it circled to another post here on PrintPlanet I remember trying to debugg that one)

It is becoming more difficult debugging since a PDF can be a placed PDF of a placed PDF of a Placed PDF... It means that you get quite complex levels of masking, and what we are given as source files may have been recycled a number of times. How many times can a PDF be recycled and the printer still responsible?

 

[Magnus]

Haven't used clipping paths in years.

Unfortunately we can't control how our customers are using the features in Indesign and Photoshop..

Is there any special file format? Tiff, PSD, JPG?

In the resent job this happend with an ordinary tif-file.

Does it happen in InDesign? Can you see it in InDesign or is it downstream in your workflow?

I can see the error in Indesign when I update the image.

I would check for double clipping paths that are near identical. Without the files can only speculate as to what is causing it. (There usually is an explanation)

No double clipping paths.. I can see if I can post the file later today.

We used to have issues like that in the old days of OPI…*one of the reasons we stopped using OPI. Would be great to know more specifics. (Lol followed the thread and found it circled to another post here on PrintPlanet I remember trying to debugg that one)

When we do our own work we never using clipping paths, but as mentioned before it's hard to control what the customers are doing.

 

[Glenn McDowall]

Was the customer supplied file InDesign CS5.5?
If it was a previous version does the same thing happen when updating the Link?
Is it possible the reason the Link required updating is that they added a clipping path?

 

[Magnus]

Was the customer supplied file InDesign CS5.5?
If it was a previous version does the same thing happen when updating the Link?
Is it possible the reason the Link required updating is that they added a clipping path?

1. Yes

2. ^

3. Good question! I have to investigate that possibility.

 

[rich apollo]

The only way I see to do what you describe is:

1) create a tiff file containing a path
2) place into InDesign
3) go back to Photoshop and define the path as a clipping path and save
4) update the link in InDesign

As a control, I imported the tiff with the clipping path disabled in InDesign, edited the tiff in Photoshop, and updated in InDesign. The overriding of the clipping was maintained.

I can create the opposite problem much more easily - getting a clipping path to DE-activate.

 

[Magnus]

Example

Example

Here you can download an example:

https://service.alfaprint.se/portal/getfiles/279402/43dc198dc1b1ea3bdf32c4656014e577

Do NOT update the link if you get that question when you open the file. Update it 'manually' when the file is open so you could see the error.

What do you think?

 

[Lukas Engqvist]

It is very hard for the customer to prove that there is just one version of the image. This image has a clipping path in Photoshop. If the previous file had the same path but it was SET as clipping path after it is very hard to tell. Can we be certain the designer wasn't placing a Low-rez file with no clipping path?

I understand since you are talking about reprint, some people may lie to your face telling you they didn't change a thing when they in fact did…*this makes the case trouble shooting harder.
Also The file is already CS5.5 so there is no way from this file we can see that the file would have been correct in 5.0.

Assuming that you did upgrade the whole suite could it be that the original file was in CS5 with a path, not explicitly a clipping path? That this path is converted to a clipping path by default if opened by PS 5.1 (from CS5.5) causing this effect? Why is the link out of date? Why does it need updating?

I placed the file deactivated and moved the file in CS5.5 all is as should be.

I turned it into CS5, and updating the link DOES NOT activate the path.
As soon as CS5.5 opens the file the default behaviour is to activate path (Here I don't even get option to update the image. It seems the default behaviour in CS5 and CS5.5 is different… I don't know how far back this goes.

CS6 will most likely be as in CS5.5…*The question is was CS5 wrong and does that mean we must live with it?

If I go and explicitly set clipping path to NONE in CS5, then the path WILL NOT activate in newer versions of InDesign, even when updating. I conclude that the error must be that CS5 finding paths by default allowing them to be there but not specifically de selected.

I would rule that it is wrong to have a an explicitly defined clipping path (from Photoshop) in a file if it is not always to be used. Saving a file with a named path but not as a clipping path, means that the designer may or may not use it…*it always needs to be explicitly chosen for it to activate or unchosen to deactivate.

Yes we cannot control how "designers" design, still they must accept the consequences of their workflow. A sign off as a digital PDF, digital print or plotter is a way to share the responsibility. No one wants to print for the bin. Is unwise workflow supposed to be subsidised by those who work responsibly?

 

[Magnus]

It is very hard for the customer to prove that there is just one version of the image. This image has a clipping path in Photoshop. If the previous file had the same path but it was SET as clipping path after it is very hard to tell. Can we be certain the designer wasn't placing a Low-rez file with no clipping path?

I understand since you are talking about reprint, some people may lie to your face telling you they didn't change a thing when they in fact did…*this makes the case trouble shooting harder.

This could be the case. BUT if you look at the path-settings on the preview image before you update the link you'll see that there's no path activated. I'v tried to re create the problem by placing an image with no clipping path, save the document and then add the clipping path to the image and update the link, and the clipping path is NOT activated by default.

Also The file is already CS5.5 so there is no way from this file we can see that the file would have been correct in 5.0.

The document we recieved couldn't be opened in Indesign CS 5.0. It's a 5.5 document.

Why is the link out of date? Why does it need updating?

I don't know, often when we get zipped documents we have to update the links.

I placed the file deactivated and moved the file in CS5.5 all is as should be.

I turned it into CS5, and updating the link DOES NOT activate the path.
As soon as CS5.5 opens the file the default behaviour is to activate path (Here I don't even get option to update the image. It seems the default behaviour in CS5 and CS5.5 is different… I don't know how far back this goes.

CS6 will most likely be as in CS5.5…*The question is was CS5 wrong and does that mean we must live with it?

If I go and explicitly set clipping path to NONE in CS5, then the path WILL NOT activate in newer versions of InDesign, even when updating. I conclude that the error must be that CS5 finding paths by default allowing them to be there but not specifically de selected.

Interesting, this might be a part of the problem.

I would rule that it is wrong to have a an explicitly defined clipping path (from Photoshop) in a file if it is not always to be used. Saving a file with a named path but not as a clipping path, means that the designer may or may not use it…*it always needs to be explicitly chosen for it to activate or unchosen to deactivate.

Sounds like 'common sense', to bad not every designer knows this.

Yes we cannot control how "designers" design, still they must accept the consequences of their workflow. A sign off as a digital PDF, digital print or plotter is a way to share the responsibility. No one wants to print for the bin. Is unwise workflow supposed to be subsidised by those who work responsibly?

We did send a ripped web proof that our customer signed off (with the fault in it but they didn't see it). Since the error occurred when we handled the document they are blaming us.. I dont know who is going to pay the bill, it's not my territory.

 

[Lukas Engqvist]

The customer is NOT always right.... just so you know.

Interesting that most printed matter has disclaimer for "print errors" but mostly it is careless mistakes from the designers that are labeled "print errors" and if there is a "print error" they want to claim that the messenger can be claimed for the error.

One way to handle this is to say... "we know it's due to bad practice, we can take the blame if you promise to commit to binding your production till we have had a chance to regain the investment in letting you know that you need to fix your workflow – AND that you (customer) will take steps to improve your workflow so that you will not cause similar problems again."

 

[Glenn McDowall]

Originally Posted by Lukas Engqvist
I would rule that it is wrong to have a an explicitly defined clipping path (from Photoshop) in a file if it is not always to be used. Saving a file with a named path but not as a clipping path, means that the designer may or may not use it…*it always needs to be explicitly chosen for it to activate or unchosen to deactivate.

If only you were a small claims court Judge

 

[rich apollo]

hmm. Couple of ineresting things.

1) when I update the image the clipping path does not activate.

2) take a look at the attached screen grab. This is before updating the image. Take a look at the placed and modified dates. That might give you enough information to prove that the image was modified on their end.

Also take a look at the instructions file within the InDesign package (Instruktioner.txt). You might get some pertinent information from there. InDesign does a nice job of tracking this stuff.

 

[Glenn McDowall]

I can get both behaviours with InDesign CS5.5
It depends on whether when you place an image the Show Import Options is checked or not. I think this is dependant on last time you used Place.
On my install when its checked the File updates without the clipping path, when its unchecked the file updates and defaults to the clipping path.

 

[Lukas Engqvist]

This rings a bell. I remember filing a bug-report years back when I was looking into an issue where PDF's were originally placed opaque, but if the last PDF placed was transparent, then updating links would cause all updates to also be transparent. My conclusion was never to use "White" but allways transparent and colour the frame white if I did not want transparency.

I have some memory of cliping paths automatically activating if dragging from bridge (that there was some difference between placing and drag dropping), also remember reporting that…*Seems time to make some test while the next release is in the forge

Very interesting observation Rich. Could be one image used for two projects, the clipping path made for the second project, and the designer "forgot" that the picture had an unclipped version (from before the time of the path) in another document. (If I send you an indd with a placed file now (link missing) and then a newer version of the file with a pink rabbit on a layer that didn't exist in the first image, updating the link would make the pink rabbit appear, but in my indesign file with a broken link there is no pink rabbit... and so I wouldn't need to pay for having it reprinted without the rabbit?)

 

[Savage]

I can get both behaviours with InDesign CS5.5
It depends on whether when you place an image the Show Import Options is checked or not. I think this is dependant on last time you used Place.
On my install when its checked the File updates without the clipping path, when its unchecked the file updates and defaults to the clipping path.

Exactly what i got.

If anyone is willing to try this:

- Open the document, don't update the link and place a file (any tiff file with a clipping path) with "Show options enabled".

- In the "Image Import Options" activate "Apply Photoshop Clipping Path"

- Update the image that was already in the file.

- Repeat the above steps, but this time deactivate "Apply Photoshop Clipping Path".

My guess is that someone changed something in that image, therefore it requires the update, but between the original placement of the image and the update, it must have been placed some image with a Clipping Path. Once the "Apply Photoshop Clipping Path" was activated, it changed the way the images were updated, and that ruined the job.

I believe it must be an Indesign bug. Can someone please test the above in CS5 our below?

 

[rich apollo]

Yep, I get the same result in 5.5.

CS4 does not exhibit the same behavior. It maintains the attributes applied to the placed graphic.

 

[Glenn McDowall]

Exactly what i got.

If anyone is willing to try this:

- Open the document, don't update the link and place a file (any tiff file with a clipping path) with "Show options enabled".

- In the "Image Import Options" activate "Apply Photoshop Clipping Path"

- Update the image that was already in the file.

- Repeat the above steps, but this time deactivate "Apply Photoshop Clipping Path".

My guess is that someone changed something in that image, therefore it requires the update, but between the original placement of the image and the update, it must have been placed some image with a Clipping Path. Once the "Apply Photoshop Clipping Path" was activated, it changed the way the images were updated, and that ruined the job.

I believe it must be an Indesign bug. Can someone please test the above in CS5 our below?

Yes you are right, it depends on activating "Apply Photoshop Clipping Path" not just the Import Options.
I still think its a bit hit and miss and can't be intentional behaviour, Each time I re-start InDesign CS5.5 the "Import Options" is de-selected, and I'm assuming Clipping Path is ON, I can't see that this default state travels with the document, only as last used by the Application.
As far as I can tell CS5 (7.0.4) behaves the same as CS5.5, when I open an .idml though the image doesn't register as modified.