Reply To: Table column widths rendering as NaN%

[Derek Read]

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

) but if you specify units it will now extract those from the @colwidth inside 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:

20"/>
20"/>

1
2

 

1
2

 

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

Reply