On Jan 4, 2006, at 14:55, gerhard oettl wrote:
<snip />
[Me:]
given:
a) that the column-numbers are all properly initialized
as far as i can see this cannot be assurred for table-cell with
the current code at the point this function is called.
Hmmm... The columns will always be available, with properly
initialized column-numbers, by the time you get to processing the cells.
A call to PropertyList.get(PR_COLUMN_NUMBER) for the table-cell
should take care of resolving the column-number for that cell, if it
wasn't already initialized. The controlling object for dealing with
implicit column-numbers is always the Table (for TableColumns) or the
TableBody/TableRow (for TableCells).
I'm not sure what you mean here, but this doesn't strike me as a
problem. Could be that I'm missing something here, though...
and b) the limited number of properties applicable to table-columns.
Mybe i see something in the spec because i want to see it ;-) but
read from the following:
"Inheritable properties may also be specified on the fo:table-column.
These can be referenced by the from-table-column() function in an
expression."
that table-columns is a countainer for _all_ inheritable properties
and
i can use it in the following manner:
<snip />
Yes! You are absolutely right, and this complicates matters somewhat.
That's one thing I always seem to forget: any property can be
specified on any FO regardless of whether it is applicable or not. [*]
... so it may be possible to map it to a call to the appropriate
method in fo.flow.TableColumn...
example: "from-table-column(1, 'border-start-width')" would
trigger a call to
"((TableColumn) Table.getColumns().get(0)).getBorderWidth
(CommonBorderPaddingBackground.START)"
This way i didn't know - i'll hava a look at it.
But only usable for props that apply to fo:table-column, since
TableColumn has no accessors for non-applicable properties. Two ways
to solve this:
1) look for the nearest ancestor to which the property in question
does apply
2) as stated earlier, keep the PropertyLists for the columns alive
until the end of the table
The first has the benefit of being a bit more memory efficient, since
PropertyLists are rather large.
The second is convenient, because it allows a simple mapping of the
function-call to: pList.get(PR_PROPERTY_ID)
Cheers,
Andreas
[*] Funny side-effect is that specifying an inherited property on a
FO to which it doesn't apply will have no effect on that FO itself
(since it will refer to the value it inherited of its ancestor) while
it does affect the descendant FOs:
<fo:block>
<fo:inline linefeed-treatment="preserve">
<fo:block>
</fo:block>
</fo:inline>
</fo:block>
The two linefeeds inside the inline are treated as spaces, while the
one in the inner-block is preserved.
