DITA and XMetaL Discussion

XMetaL Community Forum DITA and XMetaL Discussion Default column widths in tables

  • schwamkrug

    Default column widths in tables

    Participants 9
    Replies 10
    Last Activity 10 years, 7 months ago

    Hey all,

    When I create a new table via Table>>Insert Table, the default column widths are a little strange. The default is for them to be proportional, but with no proportion set (screenshot of the table properties dialog attached). This results in colwidth=”*” in the DITA code, which is ultimately the same as setting all columns to the same width. Instead, I would like NO column width to be specified by default, thus the colwidth attribute isn't set at all in the DITA code. Can I configure this in the UI somehow instead of having to empty those settings for every. single. column. when I create a new table?

    Reply

    schwamkrug

    Reply to: Default column widths in tables

    Forgot to mention that this is in XMetaL Author 6 (NOT SP1, yet). We're using it with SDL Trisoft, so in theory, this could be part of some customization they did.

    -Kyle

    Reply

    Derek Read

    Reply to: Default column widths in tables

    Inserting a CALS table with proportional colwidth set to “*” is default behaviour in XMetaL Author (all versions back to 1.0) and is not easily modifiable (it is possible but would require a new “insert table” dialog to be coded that does not call the InsertCALSTable() API and instead builds up the table using other means, or for a script to be set to run at some point after the table was inserted to modify what was inserted).

    The CALS spec says that the following are all equivalent:
      colwidth attribute not present
      colwidth = “*”
      colwidth = “1*”

    [quote=CALS spec (my highlighting in blue)]3.2.3. colwidth  column width specification

    Either proportional measure of the form number*, e.g., “5*” for 5 times the proportion, or “*” (which is equivalent to “1*”); fixed measure, e.g., 2pt for 2 point, 3pi for 3 pica. (Mixed measure, e.g., 2*+3pt, while allowed in the full CALS table model, is not supported in this Exchange model.) Coefficients are positive integers or fixed point numbers; for fixed point numbers, a leading (possibly 0) integer part is required, and implementations should support at least 2 decimal places. A value of “” [the null string] is treated as a proportional measure of “1*”.

    The fixed unit values are case insensitive. The standard list of allowed unit values is “pt” (points), “cm” (centimeters), “mm” (millimeters), “pi” (picas), and “in” (inches). The default fixed unit should be interpreted as “pt” if neither a proportion nor a fixed unit is specified.

    Declared value: CDATA

    Default: IMPLIED (means assume a proportional measure of “1*”)

    I'm trying to understand what issue setting the value to “*” causes in your system. Perhaps it is actually breaking something (in which case the other system appears to support CALS tables incorrectly) or perhaps you just wish to have a “cleaner” XML file?

    I suspect the reason we set this attribute by default is because in the past we may have seen some DTD that use CALS tables that set this attribute to be #REQUIRED (vs the CALS spec's declaration of #IMPLIED) and it may have been easier to just always insert it when that attribute is defined.

    Reply

    schwamkrug

    Reply to: Default column widths in tables

    Interesting… Yeah, I agree with your interpretation of the spec. My dilemma is this:

    Our FO processor supports . So, it's generally not necessary or even desired to set column widths.

    However, when colwidth=”*”, the DITA Open Toolkit (PDF2 plugin specifically) outputs (correctly, according to the spec). Setting the column width in makes setting table-layout=”auto” meaningless. If colwidth is NOT specified, the Open Toolkit does not specify column-width in . This is technically incorrect according to the spec.

    The root problem seems to me that DITA (or maybe the blame really lies with the CALS standard) does not have a unambiguous way to indicate a table should use auto table layout, if available.

    In the absence of that, I think I would still like to have an unspecified colwidth mean auto layout should be used, and it makes sense for that to be the default for us. At what point(s) could I run a script that removes any colwidths that are empty or set to “*”? On Save, or is there some event that fires sooner after the table is inserted?

    Reply

    Derek Read

    Reply to: Default column widths in tables

    There is an event that runs just before saving that might be used but there is the potential for conflict with the rest of the DITA functionality. Officially this part of the code is not supposed to be modified (by clients) but possible events would include On_Application_Before_Document_Validate and On_Before_Document_Save.

    Ideally, if this could be dealt with external to the XML source (ie: modify the XSLT) that would be best. Is that a possibility?

    Reply

    Derek Read

    Reply to: Default column widths in tables

    If you are really interested in pursuing this, a macro containing the following would probably do it.
    The problem (as noted previously) would be locating an event where it will not conflict with DITA functionality (and that officially making such changes is unsupported).

    //XMetaL Script Language JScript:
    var rng = ActiveDocument.Range;
    rng.MoveToDocumentStart();
    while(rng.MoveToElement("colspec")) {
    if(rng.ContainerAttribute("colwidth") == "*") {
    rng.ContainerNode.removeAttribute("colwidth");
    }
    }

    Reply

    schwamkrug

    Reply to: Default column widths in tables

    Thanks–I'll take a look at that.

    First off, I'm not a huge fan of either the script solution OR doing it in XSLT, although the XSLT solution is trivial. The reason for that is because, in both cases, I'm picking one of the values for colwidth that all mean the same thing and deciding it should mean something else. I think the real solution is for DITA to have some markup that means “use auto table layout, where applicable.”

    So… I'm not a huge fan of using such a script if it could conflict with other parts of the DITA customization. I may just use the XSLT solution for this as lesser of two evils.

    Do you guys have any documentation as to what parts of the DITA customization you guys do support users changing (besides the CSS)?

    Reply

    Derek Read

    Reply to: Default column widths in tables

    This covers a lot of it:
    http://www.slideshare.net/XMetaL/finetuning-the-dita-customization

    In addition to those things the DITA OT is also fair game but XMetaL Support doesn't help with changes beyond those described in the various Appendices related to modifying the DITA OT in Help.

    You can change how conditional text functions as described in the Help topic “Creating and modifying conditions”.

    Reply

    Derek Read

    Reply to: Default column widths in tables

    Perhaps something like this would be a good approach?

    Your XSLT would then assume any table with that attribute value, regardless of what else is set for colspec, should go through a special XSLT template that would bypass (or redefine) all the table cell/column sizing codes the DITA OT currently injects into the particular output format you are producing.

    Reply

    schwamkrug

    Reply to: Default column widths in tables

    Hi Derek,

    Yeah, that would work, and it's trivial to implement in XSLT. But it brings me back to that we really need this to be the default behavior. Is it possible to customize something so outputclass=”auto_layout” is inserted by default?

    I could also make ignoring colwidth be the default behavior, and make it that writers would need to add outputclass=”use_colwidth” or something. But, I think it might be much tougher to customize the table XSL to only pay attention to colwidth if the attribute is set… I'll have to investigate more.

    This is why I think such markup needs to be part of the DITA standard. It seems like a pretty basic thing that should be supported in all tools, be it the Open Toolkit, XMetaL, or any other DITA-enabled tool.

    -Kyle

    Reply

    Derek Read

    Reply to: Default column widths in tables

    Sounds like you've sort of decided option 2 here is the best choice (for authors).

    You might wish to also…

    a) Make a feature request here: http://sourceforge.net/tracker/?atid=725077&group_id=132728
    b) Suggest something to the DITA TC here: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support