Reply to: Change Bars and TablesJanuary 20, 2009 at 1:19 am
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.
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).
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.
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.