On Jan 5, 2006, at 11:42, gerhard oettl wrote:
On Wed, Jan 04, 2006 at 08:37:31PM +0100, Andreas L Delmelle wrote:
On Jan 4, 2006, at 20:22, Andreas L Delmelle wrote:
To expand, a little remark: try '((TableCell) pInfo.getFO
()).getColumnNumber()'
This was the beginning of my illness some days ago ;-)
It always ends with a NullPointerExection.
The following is much suspection, because i only get slowly familiar
with that powerfull concepts of mapping, events, event-like triggers
and so on (especialy about the order and the exact time when they are
called)so that i am not quite shure about the followint, but my tests
confirm my sight:
When running into the FromTableColumnFunction we are at the stage of
collecting properties "long" before the binding [1].
And you're right again... I must admit that I don't yet fully grasp
the depths of the Property system myself. More and more every day,
but still far from complete, especially the interaction with the
FOTree building/creation.
For the order i see
two possibilities:
a) left to right in the property-string
b) "unorederd" in the sense that the sax engine decides in
whitch order it delivers the properties
(may be you could clarify, but only if possible in some words -
otherwise dont matter, the time and the source will bring light ...)
It's b), AFAIU. The SAX parser presents the properties as a list of
Attributes. Except for the "font-size" attribute, the Attributes are
converted into Property objects in the order they are encountered in
the list. (see: PropertyList.addAttributesToList())
Now I'm thinking that perhaps the column-number property does need to
be bound first in TableCell.bind() for this to work properly...
this does not help because of [1]
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.
a test with the following fo-fragment arges against it:
<fo:table-body>
<fo:table-row>
<fo:table-cell display-align="from-table-column()" column-
number="3">
reports a column-number of "1", what would make case a) possible/
likely.
Not really. See: ColumnNumberPropertyMaker.make(). If I get it
correctly, the reason is that parent.getCurrentColumnIndex() will, at
that point, always return the initial value of columnIndex, since the
cell-node hasn't been added to the parent yet. addChildNode() will
not have been called, and that is the point where currently the index
is increased with each addition of a new TableCell node.
In other words, at the thime the from-table-column() is evaluated the
PropertyList does not know about the following _explicit_ column-
number.
Have you tried putting the properties in reverse-order:
<fo:table-cell column-number="3" display-align="from-table-column()">
If that works, then it's a combination of a) and b), in the sense
that it's the SAX parser that does a), and then passes the list as
such to the PropertyList, which does b).
A additional side-effect is that the call makes the wrong column-
number
"1" permanent and i get a OverlapExeception when the cell with the
realy explicit column-number "1" arises in the fo-file.
I remember raising the question of whether the whole column-number
initialization logic shouldn't be moved to the
ColumnNumberPropertyMaker. Never received an answer to it, but it
seems my suspicion was right: I put the right code in the wrong
places...
In fact, the prospect of facilitating an implementation for from-
table-column() was what drove me to move it from the layoutmgr
package to the fo.flow package. It seems I didn't go far enough, and
it needs to be moved to the properties package.
That let me see two ways (in that order):
1) Only handle descendants of table-cell, which is not a great
restriction for me, because - as shown in a previos fo-snippet -
i primary want to use table-column as info container for properties
of fo:block elements. At this time the full table-cell
(expecialy the
column-number) is available.
2) Defer all properties that need a call to FromTableColumnFunction to
be evaluated at the end of the property-collecting / parsing stage.
This is a little too tricky for me with my current knowledge of the
code and a source for later improvement.
and yes
3) I hope i am wrong with my pessimistic sight and you could lead me
out of the misery ;-))
If the move I described above is carried out, then I think the
problem can be solved for table-cells as well as their descendant
nodes. It's not going to be a trivial task though... unless I'm the
one who's being too pessimistic here ;-)
Cheers,
Andreas
