Indesign CS 5.5 (bugg with clipping paths)

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