Change Bars and Tables

[wetcoastwriter]

I have noticed that change bars don't appear when I have Track Changes on and I'm adding rows to a table (also, the deleted rows simply disappear).
I opened up a recent topic in Oxygen (since I don't have Plain Text view in XMetal), and I saw that the change codes are inserted but they are inserted in front of the property element and, so, don't appear in my working view (tags on).
I moved the change codes to be inside the cell elements and now change bars appear where I want them. I didn't mess with my deleted rows, I wasn't sure what would happen when I accepted the changes, I figured I'd end up with empty rows.
How do I get this feature to work for me? My editor wants to see the track changes.

Reply

[Derek Read]

This is expected behaviour as we have not implemented Track Changes (aka: Revision Marking) to handle table structure manipulations (ie: insertion/removal of head, body, rows, cells, foot, etc). We are contemplating this but I do not know when we might complete that work or even if we will ever do it. This limitation is applicable to both HTML and CALS table editing and so it (and the workaround below) will affect those table models for any DTD or Schema (not just DITA which uses CALS).

Note: The following is perhaps a very long-shot workaround that I would expect the majority of people to reject. If you are desperate though, you might be happy with this rather than having nothing. I offer it simply as something you may wish to try. If this workaround causes you pain or discomfort of any kind the only option is to restore the default behaviour and wait for a release that fully supports Change Tracking for table structure manipulations.

A Possible Workaround:
Turn “graphical” table rendering off for TagsOn view so that tables appear like any other set of 'boring old' elements. The INI variable for this is: [code]tags_on_graphical_tables = false[/code]

I am attaching a screen capture (tags_on_graphical_tables.jpg) that shows both TagsOn and Normal views for a CALS table containing Change Tracking for row elements (one insertion and one deletion). The same document is displayed in both images.

Note: XMetaL must be restarted for INI variables set in the INI file to be read in and have an effect.

You may wish to tell XMetaL Author Enterprise to open documents in TagsOn view by default. The setting for this is in Tools > Options on the View tab.

To make editing slightly easier while this INI variable is set, you may also wish to modify the CSS files used by your DTD or Schema to render the elements that make up the table using a different display style (perhaps by setting display:block for everything, or at least table rows). An alternative to this would be to do the vast majority of your table structure changes (provided they do not need to be tracked, see limitations below) in Normal view and only switch to TagsOn when you need to track them. I'm guessing this probably defeats the entire purpose, but I can never really be 100% how any particular client is using the product inside their workflow.

Limitations:
If you do try this INI variable workaround you must always work in TagsOn view whenever you are adding or removing portions of a table and you wish those actions to be tracked. Making these changes in Normal view will give you the same behaviour you are currently seeing: Change Tracking will still not be performed (insertions and deletions). Switching to Normal view (to view the table as a table) should be OK (ie: your XML source, which contains the PIs that track changes, should remain unaltered) but you will not see inserted or deleted elements that make up the table structure. Finally, you must not use any of the table editing functionality on the Table toolbar and Table menu, but instead must only insert elements using the Element List. Using the Tab key and the Enter key will also likely not do anything (your results may vary).

More Limitations?
If you find other limitations with this workaround (and hopefully something that in turn works around those) please share.

So, relative to using the standard graphical view, you will need to be a bit of a table editing wizard and fully understand the model for the table type you are using. It may be harder to easily see how many cells you have in each row and if you have any spanned cells (across rows or columns) that may be tricky to figure out.

Warning:
Please also note that although I believe it may be a valid workaround for some (very knowledgeable) people I would ask that you test it as much as possible using non-production documents (ie: test files) before deciding if this solution is right for you and your users.

Reply

[Derek Read]

One more point. I notice you state that your PlainText view is disabled. This is common when certain CMS systems are used (we provide CMS vendors that create integrations with a setting to turn it off) and is usually done so for good reason (editing in PlainText view can mess up some XML source the CMS may rely on that must be there but that authors should never touch). Note that the same setting (to turn on PlainText) is available to non-CMS customizations as well as it is a standard API included with the product.

If this is the case you will also want to check with whomever manages that system that this workaround isn't going to mess things up by inserting Change Tracking (which uses PIs) into documents. It is possible that such 3rd party software assumes you could not do that (given the limitations) and might not expect to see it.

Reply

[marg]

It's 7 years after the last post on this thread and I'm using XMetal version 9.0.0.053. It appears that when I delete a table row with track changes on, it's gone for good and is not marked with track changes markup. Is this still true?

Thanks,
Mark

Reply

[Derek Read]

Yes. No versions of the software have a feature that might do what you are looking for, up to and including version 11.

Reply

[Author]

Posts