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

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-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 ;-)



Reply via email to