Workaround: CALS Table Editing Behaviour (Columns Do Not Autosize as with HTML)

[Derek Read]

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:
[code]CALS_table_auto_layout = true[/code]

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

Reply

[linjinwei]

I have a problem that requires changing of table width.

Not sure if this is the solution but I hav some questions
1)what is the name of the ini file? can you specify the path name?
2)Where do I add the Code? [code]CALS_table_auto_layout = true[/code]

Reply

[mag3737]

The INI file for XMetaL is in the XMetaL installation directory under Program Files.  For XMetaL version 5.1, the full path is usually the following:

C:Program FilesXMetaL 5.1Authorxmetal51.ini

Reply

[linjinwei]

It sems like this CALS Table Auto-Layout Feature makes the width of the table equal to the number of text in it when you view in Normal View.

However when I output in pdf, the resulting table will always be the full width of the page.

[img]http://img20.imageshack.us/img20/6822/tablewidthproblem4xn3.th.png[/img]

[img]http://img213.imageshack.us/img213/6156/tablewidthproblem5xc6.th.png[/img]

My guess is this feature does not affect the output. Am I right?

Reply

[linjinwei]

Sooo….am I right

Reply

[ghkrause]

You are right! This thread is titled “CALS Table Editing Behaviour …”.
Getting the expected PDF output is a challenge and may require reading some books on XSL-FO or RenderX. We use our own XSLT and publish PDF through Framemaker. This does not make it simpler except that I have an IT guy that knows how to program code for Framemaker but none that knows XSL-FO 🙂
I attended more than 3 days training on XSL-FO but lack practice to answer your question … and would go to an external consultant to do this kind of work as you do not change layout often after the initial pain. If you plan to do layout adoptions every month than you should get a pro in this discipline yourself.

Reply

[dcramer]

My solution to this problem is to use a processing instruction (the space after sbr is important). Then for pdf output, I have a template in my xsls that turns the sbr PI to a zero width space:

​

Now, instead of this:

/some/really/long/path/that/doesnot/fit/in/a/cell

I do:

/some/really/long/path/that/doesnot/fit/in/a/cell

In XMetaL, it breaks where the s are because of the space. In the pdf output, it also breaks there because of the zero-width space added by my template. In html, the s are discarded because the table can become as wide as it needs to be and the user will have a horizontal scroll bar. It is NOT desirable to put zero-width spaces in html too because users tend to cut and paste from html output and the invisible characters in code samples would cause them grief.

This is useful in tables, where the content might not fit and sometimes even outside of tables when some property name or path is really long and produces an ugly break in a normal para.

David

Reply

[edward23]

In XMetaL, it breaks where the s are because of the space. In the pdf output,
Ah IC

Reply

[Author]

Posts