Pages: 1
Print
Author Topic: Tables not rendered in XMetaL 11 and 12  (Read 282 times)
scott44
Member

Posts: 4


« on: September 08, 2017, 08:25:34 AM »

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.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2502



WWW
« Reply #1 on: September 08, 2017, 12:43:58 PM »

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.
Logged
scott44
Member

Posts: 4


« Reply #2 on: September 19, 2017, 11:13:58 AM »

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.


* Table Anomaly in XMetaL 12.jpg (384.76 KB, 1507x1385 - viewed 31 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2502



WWW
« Reply #3 on: September 19, 2017, 04:26:21 PM »

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).

 <Tables>
    <CustomTable useFindInsertLocation="true">
      <table>Table</table>
      <row>TableContentsRow</row>
      <cell>TableEntry</cell>
    </CustomTable>
  </Tables>


The <Tables> section should be made a sibling of the <ElementPropertiesList>, <Templates>, <ChangeLists>,  <OCXReplacements>, and <Images> sections in the CTM file.
« Last Edit: September 19, 2017, 04:28:42 PM by Derek Read » Logged
scott44
Member

Posts: 4


« Reply #4 on: September 20, 2017, 08:05:07 AM »

You are correct that our customization is old.  It was originally developed ~2003 using XMetaL 3.  Your recommendation to add the <Tables> 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 4x4 table is initially rendered as a 1x1 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.


* Table Anomaly (2) in XMetaL 12.jpg (148.34 KB, 1249x408 - viewed 24 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2502



WWW
« Reply #5 on: September 20, 2017, 03:16:43 PM »

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).
« Last Edit: September 20, 2017, 03:22:16 PM by Derek Read » Logged
scott44
Member

Posts: 4


« Reply #6 on: September 20, 2017, 04:31:18 PM »

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 <row> and <cell>.  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.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2502



WWW
« Reply #7 on: September 22, 2017, 01:52:27 PM »

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.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2502



WWW
« Reply #8 on: September 22, 2017, 01:58:32 PM »

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?
« Last Edit: September 22, 2017, 02:01:21 PM by Derek Read » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2502



WWW
« Reply #9 on: September 22, 2017, 02:07:02 PM »

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.
Logged
Pages: 1
Print
Jump to:  

email us