Pages: 1
Print
Author Topic: Table column widths rendering as NaN%  (Read 4313 times)
Scibert
Member

Posts: 25


« on: May 23, 2012, 02:57:54 PM »

In XMetaL 7.0, table columns are rendered with a width of NaN% when generating output to WebHelp. The screen shot illustrates DITA code as it is rendered to HTML. Is this a bug in XMetaL or the DITA Open Toolkit? Is there an easy solution to this issue?


* table.png (40.9 KB, 1066x347 - viewed 721 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #1 on: May 23, 2012, 04:36:14 PM »

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 <td> 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.
Logged
Scibert
Member

Posts: 25


« Reply #2 on: May 23, 2012, 04:57:39 PM »

Hi Derek,

Thanks for the quick reply. I will log the defect with the DITA Open Toolkit project, as you suggested. I suspect the defect resides in the dita2htmlImpl.xsl file, where one of the templates is trying to access the colwidth attribute in the <entry> element instead of the <colspec> element.
Logged
Scibert
Member

Posts: 25


« Reply #3 on: May 23, 2012, 05:35:07 PM »

I believe I found a solution/hack, which uses the column widths entered in XMetaL along with specified units (px, pt, in, cm, etc.).

In the dita2htmlImpl.xsl file of the DITA Open Toolkit, replace this line:

<xsl:value-of select="($thiswidth div $totalwidth) * 100"/><xsl:text>%</xsl:text>

with this line:

<xsl:value-of select="../../../colspec[number($entrypos)]/@colwidth"/>
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #4 on: May 23, 2012, 06:47:15 PM »

I'd say that's a pretty good hack (I'd actually call it a good, but specific, workaround). Basically it means you must specify units.

For others reading, this is not a complete fix. It will make it so that the conversion from "CALS proportional" to "HTML percentage" no longer happens (you'll end up with "*" or "*N" where N is a number in your @width in the <td>) but if you specify units it will now extract those from the @colwidth inside <colspec> and dump them directly into the HTML output unmodified. This avoids the "NaN%" problem (the original issue).

Note that this workaround will give you incorrect values in the HTML in one particular case (though they will look like valid HTML width values). So, you might watch out for that. It will occur when no units are specified at all, as follows:

<table>
   <tgroup cols="2">
       <colspec colnum="1" colname="col1" colwidth="20"/>
       <colspec colnum="2" colname="col2" colwidth="20"/>
       <thead>
          <row>
            <entry colname="col1">1</entry>
            <entry colname="col2">2</entry>
          </row>
      </thead>
        <tbody>
          <row>
            <entry colname="col1">1</entry>
            <entry colname="col2">2</entry>
          </row>
        </tbody>
   </tgroup>
</table>


In CALS when no units are specified and the width is not proportional (ie: no "*") the default unit is assumed to be "pt". In HTML when no units are specified the units are assumed to be "px" (and CALS specifically does not have the equivalent of pixels). You might use this as an additional hack though. On most screens XMetaL will probably render "pt" close enough to an equivalent number of pixels (there are 72pt in an inch and in most cases you can assume 96px/inch) so you might get a fairly close approximation of what the table will look like in output. Keep this in mind if you use this though, in case the DITA OT changes in the future to support units with the corresponding conversion from pt to px.

I guess it depends on what your table content is, but my feeling is that it generally makes sense to use proportional sizes and let things just flow for outputs like HTML. I think most of the time we're not shooting for pixel-perfect layouts when it comes to tabular content in HTML (where table sizes are going to expand anyway if the content is too large to fit -- that's just part of the HTML spec). Unfortunately, if you do output to PDF and have 'fiddly' content then you are also dealing with a fixed page size. In extreme cases you might even end up needing to conditionalize for these two different outputs.

The CALS spec is very complex and the DITA OT only deals with a portion of what is allowed (it doesn't deal with column ordering for example and always assumes <entry> elements are in order in the XML). I think it's a little odd that IBM settled on the use of CALS for DITA in the first place when I believe their main output goal at the time was primarily HTML (so why not use HTML tables?) -- but I suppose the original requirements are lost and we may never know the reason for that.
Logged
Pages: 1
Print
Jump to: