On Aug 17, 2006, at 23:54, Andreas L Delmelle wrote:
Hi all,
<snip />
That default column gets the initial/default value for column-
width, which is defined in FOPropertyMapping as 'proportional-
column-width(1)'...
Somehow this needs to be revised, I think, as the Rec considers
this an error. We need a valid default for both situations.
As a temporary measure, I've added explicit table-layout="fixed" to
the broken testcases to make them pass, but I guess we need a more
permanent solution anyway.
Maybe 'auto' should be allowed (at least internally)?
FWIW, as also mentioned in a reply to Patrick in Bugzilla 40271, I
immediately went to work and enhanced it all a bit... At least,
that's what it looks like to me. :/
Just checking here first if anyone sees a problem with the following:
1) changed the default column-width in FOPropertyMapping
from "proportional-column-width(1)" to "auto"
=> in the PropertyList, EN_AUTO will be the value if none was
specified on the FO
2) in TableColumn.bind(), check for this, warn and replace the
EnumLength
from the PropertyList with a new TableColLength(1.0, this)
(strictly speaking, only in case of fixed-layout, but: see below)
In the same run, I altered the Table-related FOs to construct default
columns, setting the width and column-number from the cells, if
processing the first row and the table has no explicit columns.
This means that ColumnSetup now always has as many columns (and
widths) available as there were cells in the first row of the table.
For Patrick this means practically no change, except that columns
with unspecified widths would, in the strict case, now have the value
of EN_AUTO. Since I don't want to make his life more difficult, FTM I
also do the replacement for auto-layout (but silently: there will be
no warning, since it is not incorrect to omit column-width specs in
that case)
Seems to work nicely. Going to run a bit more rigorous tests later
on. If no-one objects, commit will follow tonight or tomorrow.
Cheers,
Andreas
