InDesign-InCopy workflow suggestion

[amaarora]

Hi,

I am Aman from InDesign team at Adobe.

I just stumbled across the below behaviour and wanted to know from you all as to how users and designers use this workflow in thier work.

Workflow Steps:

1. Created an InDesign document and added a frame with text
2. Applied a swatch (say 'Cyan') to some text in the frame
3. Exported this frame as InCopy- part of a new assignment
4. Now opened the icml of this frame in InCopy
5. (Optional)Checked out the story in InCopy and added some text. Checked in the icml 
6. Now in InDesign delete the swatch added to text- 'Cyan' in this case
7. InCopy story does not show any error such as 'out of date link' in the Assignment panel
8. As a result, now when the icml is checked-in from InCopy and updated in InDesign the swatch-'cyan' comes back

• The  same issue happens when instead of the swatch the steps are done with a style (paragraph/character) 
• The same issue also happens when swatch is deleted from InCopy and the status of icml is checked in InDesign
• As a side note, the 'Place and Link' functionality overcomes this issue and child frame shows an error in case a swatch swatch applied to text in parent frame is deleted

A small video: https://adobe.ly/38K3jDF

So my questions are:

1. Would you want the Assignment panel to show 'out of date link' / 'modified link' message when such steps are done? 
2. If not, does the existing workflow solve some unknown use-cases that I am not aware of?
3. Is the current behaviour in line with the InDesign-InCopy paradigm? 

Any suggestions or information resources will be helpful

Thanks

[Frans v.d. Geest]

Is this Cyan behaviour part of the Paragraph shading we saw in a different way (like not deleted etc).

If the cyan is used and the deleted,  the appearance of the text is changed, so yes of course I would expect an Out of date message! And of course I don't expect the cyan coming back.

But this is so obvious that I wonder if I'm missing your point...

That said: focus first on the enormous, enourmous bug of text in a pop up showing up as big text in the Layout mode and therefore making a mess of the Layout. It is over  six months that I reported this and the bug base and one big client can not use the workflow because if that still!

[amaarora]

No. The shading one was a different issue- 'Cyan' was shown as a used swatch in that.

 I agree that it seems so obvious and we havent heard any such concern of this sort-on this forum or otherwise. Hence, I thought of asking InCopy users and ACPs because I felt that I was missing some peice in my understanding  

Regarding your other concern: If you mean the 'Anchored item large text issue' you had reported, we did some investigation on it. But long story short, it would be really helpful if you can share with me another icap/icml/icap for the issue

Thanks

[Frans v.d. Geest]

Yes, sorry, the anchored item bug. If memory serves me well I attached an example file, but you can of course create your own fresh example including the same kind of elements and run it  through the IC workflow(!)...

[amaarora]

Bumping up for discussion...

[Dirk Becker]

Let me rephrase one scenario:

An icml / assignment embeds objects because these objects are referenced by the text.

The assignment is not checked out by InDesign, thus the assigned stories are locked against changes.

InDesign performs changes on the objects so that the footprint of those objects in the icml would change, on a fresh export.

Later on, that out-of-sync icml is edited by InCopy and InDesign is confronted with the incoming previous state of the offending objects.

From that view, the actual problem is far earlier than the link state for the assignment, or the current behaviour to resolve the collision as if the icml would be an incoming snippet place (add the missing objects).

In the first place InDesign should have avoided to produce the collisions, reject any such changes until all referencing stories are checked out to InDesign. In other words, the lock is now only enforced against text contents, it should include everything in the icml. When checked out, any relevant change should mark the stories as dirty causing re-export of the modified icml.

If you go down that route, please also ensure that required functionality is extensible - similar to the icml format. E.g. my plug-ins support an own article structure similar to but older than InDesign's. And unlike InDesign's article structure mine also makes it into the icml ...

So any style/swatch/etc. editor should first test whether all referencing assignments are checked out to InDesign, otherwise in validation reject the modification (or even offer check-out UI!). In assignment UI you could also indicate the kind of change when a user is confused why the story was modified, without any text changes.

At the scripting side, I'd either introduce a related error code, or even an event that would allow a scripter to identify and eventually check out the offending stories. I guess that somewhere below IAMServiceProvider could also need a similar notification.

As you're asking for unknown use-cases, make sure all different ways of matching (m_INXMatch* ScriptInfo metadata) are covered. You were only thinking of delete, InDesign could also just rename objects that are matched by p_Name. I'd also watch out for XML structure tags, conditional text, text variables. I haven't yet looked at those, how about PDF export/comment anchors?