Chapter 3. How To Specify Tables And Columns Width

Chapter 3. How to specify tables and columns width
Prev	Next

Chapter 3. How to specify tables and columns width

Introduction

This chapter describes different methods, which may be used to specify the width of tables and columns in an eAIP. For each method, advantages and disadvantages are listed, together with the expected result in HTML and PDF.

Background: available options

The eAIP DTD allows 2 ways of specifying a width: by using a class and by using the width attribute. When using a class, further options are possible, depending on the target format (HTML or XSL-FO). All these options are detailed below.

In the eAIP DTD

Table-related elements in the eAIP DTD are imported from the XHTML Modularization, itself derived from HTML 4.01. Consequently, the options in an XML eAIP are very similar to those in HTML.

On a table element:

• class attribute: names of style classes (ex: "col1 largeFont"), which are defined in a CSS file for HTML and in an XSLT style file for XSL-FO;

• width attribute:

  • "[decimal]%": relative to available horizontal space (ex: "66.6%");

  • "[integer]": number of pixels (ex: "350"), which are roughly converted to physical units when converting XSL-FO to PDF.

On a col or colgroup element:

• class attribute: names of style classes (ex: "col1 largeFont"), which are defined in a CSS file for HTML and in an XSLT style file for XSL-FO;

• width attribute on colgroup and col :

  • "[decimal]%": relative to available horizontal space (ex: "66.6%");

  • "[integer]": number of pixels (ex: "350"), which are roughly converted to physical units when converting XSL-FO to PDF;

  • "[integer]*": proportional width, relative to the other columns (ex: "10*"; "*" is equivalent to "1*").

In HTML, via CSS

The CSS "width" property allows to specify any element's width. Five options are possible:

• "[decimal][unit]": units are em (relative to current font-size), ex (relative to the height of a letter x, in general), px (pixel), in (inch), cm, mm, pt (point), pc (pica); ex: "1.2em";

• "[decimal]%": relative to the containing block (ex: "66.6%");

• "auto": this is the default, see the CSS specification for more details;

• "0": no unit is necessary for a zero-width column.

In XSL-FO, via XSLT

XSL-FO has an "inline-progression-dimension" attribute on the table element and a "column-width" attribute on the "table-column" element. These attributes are created in XSLT inside an attribute-set. Attribute-set elements define classes used in XML, and are named accordingly.

On a table element:

The table should have its attribute "table-layout" set to "fixed" (we don't cover the "auto" layout in this document; advanced FO developers might want to try, though). Then, the "inline-progression-dimension" is set with either of the following:

• "[decimal][unit]": units are similar to CSS: cm, mm, in, pt, pc, px (see discussion below), em;

• "[decimal]%": relative to the containing block (ex: "66.6%").

On a table-column element:

The column-width attribute can take the following formats:

• "[decimal][unit]": units are similar to CSS: cm, mm, in, pt, pc, px (see discussion below), em;

• "[decimal]%": according to the official XSL-FO specification, this format should be avoided.

• "proportional-width([integer])": proportional width, relative to the other columns

Unit definition and conversion

Sources: [XSLT], section 5.9.13 Definitions of Units of Measure and [CSS2], section 4.3.2 Lengths.

Absolute units

• 1in (inch) = 2.54cm

• 1pt (point) = 1/72in ~= 0.35mm

• 1pc (pica) = 12pt = 1/6in ~= 4.23mm

Relative units

• 1em = the font size of the current font (if computed on a property other than font size), or of the parent element's font (if computed on a font size)

• 1ex = the "x-height" property of the current font (often equal to the height of the "x" letter)

• 1px (pixel) = 1 dot on a "typical computer display" ~= 0.28mm (relative to the display resolution: for a precise definition, see [CSS2], section 4.3.2 Lengths and [XSLT], section 5.9.13.1 Pixels)

So, what is the problem?

Pixels

The only way to specify a fixed column width directly in XML is by using pixels. A pixel is a very concrete unit on screen (where it is defined as being one dot on the monitor), but not on paper. So, in XSL-FO, a pixel is converted to a device-dependent measurement as defined in the XSL-FO specification. The result depends on the XSL-FO renderer. Consequently, the same XSL-FO can produce 2 very different PDF or Postscript files.

Screen is not paper

You might very well want to present a table differently on screen and on paper, for esthetic and/or practical reasons. This can obviously not be achieved by specifying the same width for both targets. The only way to do it is by giving a separate width value for each format.

Usability

Usability studies recommend a flexible layout in HTML, in order to accommodate different browser window sizes. Indeed, a table that looks good on a large screen with a high resolution may very well looks partially hidden on a smaller screen, if the table has a fixed width. On the opposite, the size of a sheet of paper is known in advance, so it makes sense to fix table layouts in XSL-FO. However, in some cases, one might want to write XSL-FO code that can adapt to several formats. For example, the same XML table could be used to generate a table in an AIP on A4 paper and also a flight manual in A5 format.

Automatic table layout in XSL-FO (or lack thereof)

The XSL-FO Specification provides 2 ways to define the layout of a table: fixed and automatic. However, current implementations of XSL-FO only accept the fixed layout or have a somewhat unreliable automatic layout.

Solution 1: column class (recommended solution)

This solution consists in using the class attribute on each col or colgroup element in a table. Nothing is specified on the table element.

<x:table> <x:caption>Solution 1: x:col/@class only</x:caption> <x:col class="sol1-col1"/> <x:col class="sol1-col2"/> <x:col class="sol1-col3"/> <x:tbody> <x:tr> <x:td>This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph.</x:td> <x:td>Narrow column</x:td> <x:td>Narrow column</x:td> </x:tr> </x:tbody> </x:table>

Advantages:

• The total table width is not fixed, which makes the table fluid in HTML (see the narrow window example in HTML);

• Column widths are only specified through classes, which allows having different sets of widths for HTML and for PDF/paper;

• By reducing the number of these classes, tables will tend to look the same, increasing visual consistency and, hence, readability (for example, many tables have the same 3-column structure in AD-2.x/3.x sections and would benefit from looking alike).

Disadvantages:

• There must be 1 distinct class for each and every unique column width concerned by this solution, and each class must be defined in 2 places (CSS and FO styles).

We recommend this solution because it is the safest regarding window size and because it is the most flexible one.

Note

We suggest that it is implemented by using a separate CSS file, so that the main CSS file does not become too large and unmanageable.

Solution 2: table class and proportional column width

This solution consists in using the class attribute on the table element and the width attribute on each col or colgroup element, expressed in proportional values. The table's class is used to fix the total table width.

<x:table class="sol2"> <x:caption>Solution 2: x:table/@class &amp; x:col/@width=n*</x:caption> <x:col width="7*"/> <x:col width="2*"/> <x:col width="1*"/> <x:tbody> <x:tr> <x:td>This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph.</x:td> <x:td>Narrow column</x:td> <x:td>Narrow column</x:td> </x:tr> </x:tbody> </x:table>

Advantages:

• Table widths are only specified through classes, which allows having different widths for HTML and for PDF/paper;

• By reducing the number of these classes, tables will tend to look the same, increasing visual consistency and, hence, readability;

Disadvantages:

• The total table width is fixed, so the table is not fluid in HTML (see the narrow window example in HTML);

• There must be 1 distinct class for each and every unique table concerned by this solution, and each class must be defined in 2 places (CSS and FO styles); but, compared to solution 1, the number of classes are greatly decreased;

• Formatting information (column width) is mixed with text and data; that is the opposite of one of our goals in using the XML format.

Alternatively, the class attribute on table can be replaced by a width attribute and a percentage: this works fine for both HTML and XSL-FO on all platforms. It does not work with pixels, though (see Solution 3).

We recommend this solution only when the tables are small enough that there is no risk that they will be hidden inside a narrow window.

Note

We suggest that it is implemented by using a separate CSS file, so that the main CSS file does not become too large and unmanageable.

Solution 2bis: table class and column width in %

This solution is similar to Solution 2, except that the widths are expressed in percentage. Advantages and disadvantages are the same as for Solution 2, except 1 more disadvantage: the XSL-FO Specification recommends to avoid using percentages in column widths, because it can lead to unreliable result.

<x:table class="sol2"> <x:caption>Solution 2bis: x:table/@class &amp; x:col/@width=n%</x:caption> <x:col width="70%"/> <x:col width="20%"/> <x:col width="10%"/> <x:tbody> <x:tr> <x:td>This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph.</x:td> <x:td>Narrow column</x:td> <x:td>Narrow column</x:td> </x:tr> </x:tbody> </x:table>

Solution 3: column width in pixels

This solution consists in using fixed column widths in pixels and nothing on the table element.

<x:table> <x:caption>Solution 3: x:col/@width=n (pixels)</x:caption> <x:col width="350"/> <x:col width="100"/> <x:col width="50"/> <x:tbody> <x:tr> <x:td>This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph.</x:td> <x:td>Narrow column</x:td> <x:td>Narrow column</x:td> </x:tr> </x:tbody> </x:table>

Advantages:

• The total table width is not fixed, which makes the table fluid in HTML (see the narrow window example in HTML);

• The number of classes is drastically reduced (not sure if it is really an advantage, though).

Disadvantages:

• Formatting information (column width) is mixed with text and data; that is the opposite of one of our goals in using the XML format;

• The pixel is not precisely defined in XSL-FO.

Solution 4: no width specification at all

This solution consists in letting the browser or the XSL-FO renderer lay out the table as it sees fit.

<x:table> <x:caption>Solution 4: no width at all</x:caption> <x:tbody> <x:tr> <x:td>This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph. This is a long paragraph.</x:td> <x:td>Narrow column</x:td> <x:td>Narrow column</x:td> </x:tr> </x:tbody> </x:table>

Advantages:

• We do not need to bother at all about width: we let the rendering software do the work;

• The XML source is "clean".

Disadvantages:

• The rendering software might not do a very good job... (see PDF screen shots below)

Other solutions

Table width only

Another alternative would be to specify the total table width with the width attribute, but not to specify any column width. This alternative might make sense for HTML only, but is not acceptable in XSL-FO, for the same reason as in Solution 4. (We do not provide this example in the screen shots below.)

Table width in pixel and column width

If we provide table width via the table's width attribute and column width either with a width or class attribute, the result is not reliable, because of the pixel definition in XSL-FO. (We do not provide this example in the screen shots below.)

Complete example

Using all the examples above, combined in a single file, we generated the HTML and XSL-FO files. We can now compare all results with the screen shots below.

Result in HTML

Style sheet:

.sol1-col1 { width: 350px; } .sol1-col2 { width: 100px; } .sol1-col3 { width: 50px; } .sol2 { width: 500px; }

Screen shots

The complete example above, converted to HTML and displayed within Mozilla 1.1 browser (equivalent to Netscape 7).

The complete example above, converted to HTML and displayed within Internet Explorer 5.5.

The complete example above, converted to HTML and displayed within Mozilla 1.1 browser, this time with a narrow window. Note that some tables are not completely visible: a scroll bar has appeared in the bottom to scroll horizontally. Internet Explorer 5.5 displays this example in exactly the same way (see further down).

HTML findings

1. Solutions 1 and 3 have exactly the same column widths, specified in pixels;

2. Solutions 2 and 2bis have almost the same width as 1 and 3. The difference is probably due to rounding;

3. Solutions 2 has exactly the same width as 2bis, but their columns are very different, strangely enough (note that proportional column width is not implemented in Internet Explorer 5.5);

4. Solution 4 works pretty well for HTML: the table takes as much space as available and column widths are set depending on cells' content;

5. Not all tables adapt to a narrow window: only those without table width specification (either in XML or in CSS) are adapted while the others are partially hidden.

Note

A workaround for IE 5.5 bug regarding proportional widths is to use a proportional value which gives good results in pixels as well (for example, use 60* instead of 1* will have IE show a column of 60 pixels width). This way, correct implementations of proportional widths will show the right proportions, while IE will fix the layout in pixels, just like Solution 3. As always the case with this kind of bug, only a series of trial and error can lead to acceptable results. We did not use this workaround in these examples.

Result in PDF

Style sheet:

<xsl:attribute-set name="sol1-col1"> <xsl:attribute name="column-width">10.5cm</xsl:attribute> </xsl:attribute-set> <xsl:attribute-set name="sol1-col2"> <xsl:attribute name="column-width">3cm</xsl:attribute> </xsl:attribute-set> <xsl:attribute-set name="sol1-col3"> <xsl:attribute name="column-width">1.5cm</xsl:attribute> </xsl:attribute-set> <xsl:attribute-set name="sol2" use-attribute-sets="table"> <xsl:attribute name="inline-progression-dimension">15cm</xsl:attribute> </xsl:attribute-set>

Screen shots

The complete example above, converted to XSL-FO, then converted to PDF with XEP 2.77 and displayed within Acrobat Reader 5.

The complete example above, converted to XSL-FO, then converted to PDF with FOP 0.20.4 and displayed within Acrobat Reader 5.

PDF findings

1. Solutions 1 and 2 have exactly the same column widths, as expected;

2. Solutions 2bis is correct with XEP but not with FOP (percentages are not implemented in FOP 0.20.4);

3. Solutions 3 is different between XEP and FOP because their pixel conversion method is different;

4. Solution 4 does not work for neither XEP nor FOP: XEP gives equal width to each column while FOP does not accept unspecified column width and does not render the table at all.

Conclusion

Table 3.1.

Solution	HTML			XSL-FO
	Mozilla1	IE 5.5& IE62	Narrow window	XEP	FOP
1. x:col/@class	OK	OK	OK	OK	OK
2. x:table/@class & x:col/@width=n*	OK	workaround	workaround	OK	OK
2bis. x:table/@class & x:col/@width=n%	OK	OK	workaround	OK	X
3. x:col/@width=n (pixels)	OK	OK	OK	X	X
4. no width at all	OK	OK	OK	X	X

Note

• 1 Tested with Mozilla 1.1 on Windows only, but Mozilla looks the same on all platforms; Netscape 7 is based on Mozilla 1.0.1 and looks just like Mozilla 1.1 for this matter.

• 2 Tested only on Windows; Internet Explorer 5 for Mac can look very different; IE6 has with very similar result to IE 5.5, so no screen shot is provided.

Solution 1 is the safest in all cases: this is the one we recommend.

Solution 2 can be appropriate for narrow tables, for which we can be sure they will not be too wide for a reasonable screen resolution. Also, for tables with many narrow columns (but of variable width), this solution can be appropriate, since it is less verbose.

Solution 2bis is to be avoided as long as FOP does not support percentage values. Even if you do not use FOP yourself, remember that your eAIP in XML is could be used directly by your users, and they might use FOP. Moreover, the XSL-FO Specification itself discourages using percentage values.

Solution 3 is definitely to be avoided, since the result is unpredictable.

Solution 4 should be avoided until automatic table layout is available and reliable in several XSL-FO renderers.

Prev	Up	Next
Chapter 2. eAIP Directories Organisation	Home	Chapter 4. Amendment Procedures