Table with proportional and absolute column widths do not render properly

[antonyterrence]

If a DITA CALS table uses both proportional and absolute widths, the column with the absolute value appears too narrow to display content properly.
For example, if a table has the following colspecs, then the second column appears too narrow in the output (HTML).

Code: Select all

<colspec colname="c1" colnum="1" colwidth="1*"/>
                    <colspec colname="c2" colnum="2" colwidth="4in"/>

If a table uses only the proportional values or absolute values, the table is rendered correctly (at least, column widths are distributed proportionally).

[Radu]

Hi Antony,

Right, so for a DITA table like this:

Code: Select all

<table id="table_ut4_xck_15b">
        <tgroup cols="2">
          <colspec colname="c1" colnum="1" colwidth="1*"/>
          <colspec colname="c2" colnum="2" colwidth="4in"/>
          <tbody>
            <row>
              <entry>q</entry>
              <entry>b</entry>
            </row>
            <row>
              <entry>c</entry>
              <entry>d</entry>
            </row>
          </tbody>
        </tgroup>
      </table>

I get this HTML5 equivalent when publishing:

Code: Select all

<table class="table"
              id="introduction__table_ut4_xck_15b">
            <colgroup>
              <col style="width:100%">
              <col style="width:4in">
            </colgroup><tbody class="tbody">
                <tr class="row">
                  <td class="entry">q</td>
                  <td class="entry">b</td>
                </tr>
                <tr class="row">
                  <td class="entry">c</td>
                  <td class="entry">d</td>
                </tr>
              </tbody></table>

Notice in the HTML content those:

Code: Select all

<col style="width:100%">
              <col style="width:4in">

So the 4 inches column width is propagated correctly to the HTML5 document but the first column is set to "width:100%" and this seems to make the web browser fully maximize it.
I do not have a solution for this, the HTML table spans the entire page, it does not have an explicit width set to it.
The CALS table specification states:
https://www.oasis-open.org/specs/a502.htm

When any proportional parts are specified, the unit proportion is determined by starting with the target table width determined from the <table> pgwide value non-zero for full width, "0" for galley column width (possibly affected by current indents). Reduce that by sum of border widths and column ruling widths and the fixed parts of the various <colspec> colwidths to get the available proportional width.

so it states to subtract from the table width (that the XSLT processing does not know because the table width fits the displayed page width) the fixed column widths and find out the width of the proportional columns.

Maybe the solution in the HTML content would be to do something like this:

Code: Select all

            <colgroup>
              <col style="width:calc(100% - 4in)">
              <col style="width:4in">
            </colgroup>

but this does not seem to work in a web browser.
As I do not have a possible way to fix the HTML publishing I cannot add a DITA OT issue for this.
Maybe you can try to avoid using both proportional and fixed widths in tables.

Regards,
Radu

[chrispitude]

Hi Antony,

We ran into the exact same thing last week.

The browser behavior does seem to work better if you specify unallocated (blank) widths instead of proportionally allocated (#*) widths:

Code: Select all

          <colspec colname="c1" colnum="1" colwidth=""/>
          <colspec colname="c2" colnum="2" colwidth="4in"/>

but with this workaround, you cannot specify relative proportions across multiple "#*".columns.

For now, I added the following Schematron rule to warn writers of mixing proportional and fixed allocations:

Code: Select all

<pattern id="tables_error">
  <rule context="tgroup" role="error">
    <report test="colspec/@colwidth[contains(., '*')] and colspec/@colwidth[matches(., '\d') and not(contains(., '*'))]">Do not mix proportional ("*") widths with fixed widths; use blank values for automatically allocated widths.</report>
  </rule>
</pattern>

Lastly, PDF Chemistry handles a mix of proportional and fixed column widths in a smarter way (which differs from the browser behavior), but if you are developing both HTML-based and PDF deliverables from the same DITA source, then that becomes difficult to take advantage of.

- Chris

[antonyterrence]

Thank you, Chris and Radu. I have already advised the team to use one type of value consistently (in this case, proportional).

[chrispitude]

Hi Antony, Radu,

I noticed (while working on something else) that a writer can inadvertently cause this condition by inserting a new column in a table that currently uses fixed columns widths.

In the Oxygen editor, the newly inserted column has a proportional width value:

Code: Select all

<colspec colname="c1"      colnum="1" colwidth="3in" colsep="1"/>
<colspec colname="newCol2" colnum="2" colwidth="1*"/>

which causes the issue. You can see this in the following testcase by adding a new column to the table, then building the deliverables in the "project.xml" file. (This testcase also demonstrates the PDF Chemistry behavior, which is to honor the fixed column width, then still apply the full-page width to the second column.)

oxygen_adding_table_column.zip

Perhaps the behavior of Oxygen's column insertion operation could be improved here to set @colwidth to "" (or leave it unset) when any existing column has a fixed width value. (In my Schematron check, I determine this by looking for any @colwidth value that has a digit but not a "*".) This would allow the insertion operation to match the table's existing width convention of proportional values or not.

[Radu]

Hi Chris,

I agree, I added an internal issue to look more into this:

EXM-50841 Improve behavior when adding column or resizing column in table which has fixed column widths

I would be inclined that when the action to add a new table column is called for a table with fixed column widths, to insert that column with a fixed width.

Regards,
Radu

[Radu]

Hi,

As an update we fixed issue EXM-50841 in Oxygen 25, we decided that when a new column is inserted we will use the same width as the column which is located to the left of it.

Regards,
Radu