Reply To: Table column widths rendering as NaN%

[Derek Read]

Some quick tests here show that this is a general issue for all outputs that use the DITA OT's “XHTML” transtype for the main portion of their content (CHM, Java Help, Eclipse, WebHelp, etc).

From what I can tell the DITA OT ends up inserting the value “NaN” (ie: “Not a Number”) because it is dividing by 0 (division by zero is not allowed of course). It does this as it tries to create a percentage value for the

element's @width in the HTML by dividing the proportional values of the colwidth attributes in the CALS table. However, it doesn't take into account the fact that the CALS specification says “*” is equivalent to “1*”. So either the DITA OT is written to assume “*” = “0*” or, more likely, the “*” portion is simply being dropped (using some string manipulation or similar) before calculating the number to use as the divisor. Division by “null” gives the same results as division by 0.

I suspect the latter is more likely because the DITA OT gives similar results when units for CALS table column widths are specified (eg: “25.4mm”, “2.54cm”, “1in”, “72pt” and “6pi” are all valid CALS colwidth values containing units). Using units results in “NaN%” in the HTML output as well. So you should avoid using those until the DITA OT supports them.

The quick fix would be to set all colwidth values to “1*” if you want all columns to be the same size (I assume that's the case as you have not already changed them). You can do that in the Table Properties dialog in XMetaL Author Enterprise, or if you don't care if they are precise you can drag column boundaries.

You may wish to log a defect with the DITA Open Toolkit project here: https://github.com/dita-ot/dita-ot/issues
It doesn't look like this is a known issue (my search was for “NaN” and variations).

The CALS table editing capabilities are a general part of the authoring tool that is designed to follow the CALS specification, so it is designed to work the same way for all DTDs that use CALS (DITA, DocBook, etc). I can ask our developers to look into what might be done to help with this problem, but in general we don't like to dumb down our editor in order to help with limitations in other software. I think the ideal fix is to alter the DITA OT to properly support the CALS spec and perform appropriate transformation. A quick fix might be to change the files using script upon saving, replacing any occurrences of “*” in colwidth with “1*”. I'm not sure how much work that would be, but I might have a look if I have time.

Reply