🚀 go-pugleaf

Hi,

something strange occured today while playing around with the "track changes" feature in InCopy. We have documents containing text and tables. Those tables are surrounded by tags and appear on a single line (-> linebreaks before and after the tags). As a matter of principle it comes down to something like this:

Text Text Text ...
 ... Text Text \n
 \n
 [ Tag ] {TableSymbol} [ /Tag ]\n
 \n
 Text Text Text ...
 ... Text
 ...

This works fine (well, why shouldn't it) as long as the "track changes" feature in InCopy is turned off or at least no changes are made around the opening (!) tag while having tracking changes turned on. As soon as someone adds or removes a linebreak right before that tag the following happens: The next time you open the file for editing, the marker has disappeared and the tracked change is displayed with a large colored bar instead - somehow running over the formerly opening tag I guess. As soon as you put the cursor into that area, InCopy freezes and you have to kill the program using the task manager.

I can reproduce this phenomenon with clean InCopy documents - so I guess the problem haunts deeper into the internals of the adobe product?

A quick look under the hood reveals, that InCopy seems to store that changeset information using the same type of markers (<?aid Self="rc_xxx"?>) used to store the position of those tags and the table. Actually it even uses the same Self-ID for the "right end" of that changeset, leading to exactly two processing instructions (those <?aid ...?> parts) with exactly the same 'Self="..."' part - one for the changeset, one for the marker.

Is there a formal way to commit this behaviour as bug report or am I the only one facing this problem? (although tested on different InCopy installations at our company)

Thanks for any input on that topic.

Regards
Stefan