Product(s):XMetaL Author, XMetaL Author Enterprise
Description:By default, XMetaL Author lays out CALS tables according to the OASIS CALS table specification. Columns in CALS tables can be set to a specific width in units or they may be proportional to the rest of the columns in the table.
In contrast with CALS tables, the columns of HTML tables are allowed (by definition) to grow to fit the content they contain. It is possible to define widths for HTML tables, but these are minimum widths and they must grow if the content they contain does not fit within them. CALS table column widths are (normally) rigid.
CALS table columns do not normally grow larger or smaller unless you explicitly alter the width for the column by changing the width attribute for that column's colspec element (this is normally done in the Table Properties dialog on the "Column" tab).
Content that is too wide to fit inside a CALS table cell is cut off -- the right portion of the content is hidden. This is an indication to the author that the content they are editing may be too wide to fit in the cell when output is generated. This may not be true if the XML being edited in Normal view does not closely match the output (this will depend on the CSS used for Normal view and the type of output being produced -- developers setting up XMetaL Author customizations are encouraged to try to match these as closely as possible so that authors can rely on this feature if necessary).
In TagsOn view, because the tags are also visible and take up space the effect can be more pronounced (more content may be cut off) and TagsOn view should not be relied upon when checking to see if content will fit in a given cell. Ultimately, you cannot know for sure whether content will fit in a cell until you see the final output.
If Normal view has been set up to mimic a particular output format, content being cut off in Normal view may also be cut off in the output. However, this will depend on the transformation method and the final output being produced and may not apply to all authors, all transformation systems or output formats. For example, CALS tables may be used when creating XML content but that content might ultimately be transformed into HTML. Widths in HTML tables are not restrictive and so content will not be cut off because the table will resize itself to fit the content. On the other hand, the final output may be to a print format (PDF for example) in which case the width of a table cannot exceed the widh of a printed page and so column widths are ultimately fixed to a certain size and content may be cut off if it does not fit within the confines of a given cell.
CALS Table Auto-Layout Feature:XMetaL Author supports a feature that will ignore the column width attributes and resize the widths of columns to fit their content (similar to HTML tables). An INI variable must be set to turn this feature on. The INI variable is:
CALS_table_auto_layout = true
XMetaL Author must be restarted for this INI variable to be loaded and take effect. There is no equivalent setting for XMAX at this time.
This setting causes attribute values for the column widths to be ignored when rendering CALS tables during editing. Instead, every column is sized to automatically fit the widest "word" (or other content
not containing a character that is allowed to "break" a line, such as whitespace or a hyphen).
Content added or removed from a cell causes the width of the column to expand or decrease provided no other cells in that column contain content that requires a greater column width. The minimum column width (in the case where a column contains no content in any cell) is about 5 pixels to allow the end user to position the insertion point into an empty cell.
Setting a column width in the Table Properties dialog will still cause the width attributes to be inserted into the corresponding colspec element in the table, but no visual feedback corresponding to this setting will be rendered when drawing the table.
Drawbacks:The rendering of CALS tables, and editing within them, may be slower than when this feature is disabled. This will be more noticeable on slower systems, for tables containing more rows and more columns, tables with cells containing a lot of content and for tables nested inside other tables.
Clicking and dragging on column boundaries will still cause the column width attribute for that column to be altered (as when this feature is turned off). However, the actual rendered width on the screen will continue to ignore this attribute (the column width on screen will remain unaffected). So, altering column widths by clicking and dragging when this INI variable is enabled should be avoided if column width attribute values are important.
As a result you may wish to set widths automatically during post processing (transformation) to be sure they are set correctly (removing any chance for human error). Alternatively, before saving any final version of a document authors may wish to double check that column widths are correct in the Table Properties dialog (or by using the Attribute Inspector). If these values are used during transformation to the final output format then viewers of that output may readily recognize that something is incorrectly set (this will depend on the output format and how "wrong" the values are).
External References:OASIS (Organization for the Advancement of Structured Information Standards) - "CALS Table Model Document Type Definition":
http://www.oasis-open.org/specs/a502.htm
