Tables not rendered in XMetaL 11 and 12

[scott44]

We use XMetaL and customizations to author XML documents used for operational procedures.  Our browser-based procedure viewer transforms the XML documents to HTML for viewing.  The procedures may contain tables.  After a recent upgrade to XMetaL 11 (and also while evaluating XMetaL 12), we noticed tables are not rendered in Normal View and Tags On View (a very small square is displayed in place of the table).  The XML is valid, and the table tags can be seen in Plain Text View. 
In all versions of XMetaL we have previously used (up to and including version 7), the tables were rendered.  Our investigation discovered there must be a collision with the name of our XML table element and XMetaL’s rendering system.  In our schema, our XML table element is named “Table”.  I modified our schema, macros, and some sample documents to change “Table” to “myTable”.  After the modifications, the tables were successfully rendered in XMetaL.  Here are my questions:
1. Any ideas why this began happening?  Is this a bug, or a conscious design change?
2. In what version was the change/bug introduced? It had to be after version 7.
3. Is there a workaround short of changing our schema?  We have many thousands of existing documents.  Changing the schema, and therefore the existing documents, would cause a significant work impact to re-verify the modified documents.

Any help or suggestions will be greatly appreciated.

Reply

[Derek Read]

Yes, things have changed in order to better support arbitrary table models. Anything that is not CALS and not HTML (which are both supported natively and automatically) can now be both rendered and edited as a table. Previously such tables could only be rendered while none of the fancy table editing functions available for CALS and HTML were available.

Any group of nested elements at three levels (parent/child/grandchild = table/row/cell) could always be rendered as a table (using CSS) but the Table Properties dialog and the table editing functions in the Table menu and Table toolbar would do nothing. You can now identify such tables using a “Treat As Table” setting in the CTM file and that will enable this functionality.

Having said all of that, any existing table model that follows the CALS or HTML table specs should “just work” as it always has. We would need to see your DTD / XSD and a sample XML file to let you know why it isn't working in your case. The feature has likely not been tested by that many clients so I wouldn't be surprised if you've turned up an issue.

If your table model isn't CALS or HTML then we would also want to see a copy of the DTD / XSD and a sample XML file so we could let you know what needs to be set in the CSS & CTM to enable both the display and editing capabilities.

Please submit any files through XMetaL Support.

Reply

[scott44]

Thank you for the post, Derek.

While waiting to see if I can upload our XSD (it is “owned” by another group), I will add a bit of information to my previous post.

I noticed that a table is properly rendered in Normal and Tags-on views immediately after the table is inserted in the document. I can switch between the Normal and Tags-on views with no effect on the table. However, as soon as I switch to Plain Text view (or close and re-open the document), the table is no longer rendered.  I attached a picture with some excerpts to illustrate.

Many thanks.

Reply

[Derek Read]

I think the issue is that your customization is set up for the old way of doing things, which uses CSS only (and possibly complicated by the fact that the main element is named Table, which is fine, but without any additional settings the software is probably guessing if this is supposed to be HTML, CALS, other, and then maybe partially working but ultimately failing to figure it out).

If you add the following to your CTM file things should behave properly, and the new table editing behaviours will be enabled for your custom table type, including the functions in the Tables menu (that apply) and the Table Properties dialog (with functions that aren't relevant being disabled).

     
     

Table

     TableContentsRow
     TableEntry
   
 

The section should be made a sibling of the , , ,  , and sections in the CTM file.

Reply

[scott44]

You are correct that our customization is old.  It was originally developed ~2003 using XMetaL 3.  Your recommendation to add the element to the CTM file worked great (sort of).  Now I have the opposite problem, but it may be easier to deal with.  Existing tables now render correctly in Tags-on and Normal views, but a new table is incorrectly rendered when it is initially inserted.  However, after switching to Plain Text view then back to Normal or Tags-on view, the table is correctly rendered.  It seems that returning to Normal or Tags-on view from Plain Text view fires some sort of redraw event.  Is it possible to force that redraw event from macro code?
The attached picture illustrates the case.  A newly added 4×4 table is initially rendered as a 1×1 table, but after switching to Plain Text view and back to Tags-on view, the table is rendered correctly.  I am also looking at our macro code to see if we need to modify our InsertTable function.
You have been a great help.

Reply

[Derek Read]

If the table is being inserted using a macro then that would be the issue.

You might have created the macro(s) because the Insert Table menu item (in the Table menu) wasn't functional.
I would recommend trying all the newly available functions in the Table menu and if they work (which should be the case) then you likely don't need their equivalents as macros.

If the InsertTable macro does still need to be used (it might do something our menus don't) then calling the API method ActiveDocument.formatGraphicTable(nodeTblNode) on the particular table in question should get it to render as a table. See the Programmer's Guide for details (including why this is necessary).

Reply

[scott44]

Again, I am grateful for your time, but I realized we have bigger problem.  Our schema uses a different set of tags for optional column headers in our tables. For column headers, the custom row tags are ColumnLabelRow, and the custom cell tags are ColumnLabel (vs TableContentsRow and TableEntry for the data rows).  It doesn't look like the Tables element in the CTM file will allow two different custom tags for and .  So, it looks like the solution may be to change our custom table tag to de-conflict with XMetaL's table tag. 

The least disruptive (though quite inelegant) approach would be to transform the document (changing the “Table” tag to “myTable”) when the document is opened then transform it back (thus reverting “myTable” to “Table”) when saving or validating.  In other words, while the document is in XMetaL, the “myTable” tag would prevent the conflict.  By reverting the tag a lot downstream processing tools would not have to change.  I've looked at the Developer's Guide and see some references to transformations for output to PDF or HTML, but I'm not sure if the in-memory transformation is possible.  Kind regards.

Reply

[Derek Read]

I'm pretty sure this is probably supported (there are a lot of other settings available for this feature that I have not listed here).

I'll wait for you to be able to provide a copy of your schema and whatever you have currently set up as well as a sample XML file. If you can submit that to XMetaL Support we can help you configure things as needed.

Reply

[Derek Read]

Transformation would probably be best done before opening the file (if only one table model is defined in the schema). There is an event that lets you intercept a file that is being opened (the file path) that lets you do what you want with it before actually opening it.

Making modifications to the file after it is open would be tricky (to the point that I would avoid trying to do that). However, if the document model (your Schema / DTD) supports both types of tables then this would be easier.

Saving would be similarly tricky, and also probably made easier if both table models are defined in the schema. There are several events that let you make changes to a document before saving, and it would also be possible to write out a file using script (bypassing XMetaL's own save) though this needs to be done carefully.

However, having said that, I'm quite certain most table models can be supported by the table authoring feature with the right settings in the CTM file. Seeing your files will allow XMetaL Support to properly help.

Your statement that you feel it would be easier to transform to another table model (not sure which, CALS, HTML?) to make it easier to work with your documents with other downstream tools makes me wonder why you aren't just using CALS or HTML in the first place. There must be some reason for that?

Reply

[Derek Read]

If you cannot share the entire schema (for copyright or other reasons) you could perhaps just snip out the portions that define the tables and include those in a dummy partial schema for testing that you could share with XMetaL Support. All that would need to include is a root element and the table model. If sharing an XML sample would be equally frowned upon you could then also remove everything from it except the dummy root and the table, and if necessary remove or change #PCDATA or attributes to dummy but valid values.

Perhaps that will allow you to bypass any strict regulations your organization(s) has about sharing such files.

Reply

[scott44]

Hi Derek,

I was off on another task, but now back on this one.  Many thanks for your replies.  I am going to submit an excerpt of the table portion of our schema and sample XML.

Reply

[scott44]

Hello Derek,

I have excerpts from our schema and sample XML ready to send. I do not see an upload capability on the Support page.  What is the best way to submit the files?

Thanks.

Reply

[Derek Read]

You can't submit files directly through the support page. Submit a case, that will open the case and log it into the support system, the system will email you and you can reply anything you need to send.

Reply

[gj0918]

Hello,

I am facing about the same problem with XMetal Author Enterprise 12.0
XMetaL Developer 12 seems not to support the “treat as table”.
I also could not find the topic in the ‘Customization Guide’.

Could you explain the section to be entered in CTM-file?
Please add a detailed example.

Kr, Guenther

Reply

[nhu1]

Here is the sample chunk from C:\XMetaL\DITA\XACs\1.3\basemap\basemap_map.ctm

reltable

relheader
relrow

relcolspec
relcell

title

subjectRelTable

subjectRelHeader
subjectRel
subjectRole

title

topicSubjectTable

topicSubjectHeader
topicSubjectRow

topicCell
subjectCell

title

Ning

Reply

[Author]

Posts