On Dec 14, 2007, at 11:44, Vincent Hennebert wrote:

Normally not. The code dealing with border resolution is only triggered for tables which are not descendants of a marker (there are ! inMarker() guards wherever needed —which as some point will need to be replaced by
something more elegant).

I wonder what could be a more elegant approach. Do you have any specific ideas yet, or is this just a nagging feeling? (Believe me, I know those ;-))

Right now the full picture is this:
* the FOTreeBuilder is responsible for building the tree off the SAX Events * whenever it encounters a fo:marker node, the FOEventHandler is switched to 'marker-mode'; in case we have nested fo:markers, the nestedMarkerDepth member is simply increased/decreased at the start/ end of a fo:marker Note: renderers that bypass the FOTreeBuilder and catch the FOEvents directly, like RTF, cannot rely on this; although the RTFHandler does inherit the inMarker-switch, so it's a matter of handling it there instead of in FOTreeBuilder * this mode is used by the descendant nodes created by FOTreeBuilder to conditionally perform/defer some steps in the process (like white- space-handling and border-resolution)

The idea is not only to make the implementation more correct. For instance, dealing with property-resolution if and when it is needed, leads to a more correct implementation of inherited properties, relative font-sizes, percentages, etc. in case of fo:markers. Another cool advantage is that, for documents with a lot of markers, the savings on processing time should be significantly reduced if only a fraction of the markers actually gets retrieved. (A small disadvantage if one single fo:marker gets retrieved multiple times into an identical context... Then again, IIC, there is currently no caching going on whatsoever when it comes to static-contents. This might be something worth considering: re-use a StaticContentLM's element-list and re-run it through the algorithm after substituting the sublists corresponding to retrieved markers.)

The basic idea is this: when a table is a descendant of a marker,
nothing more is done than recording its children FO elements; only when the table is retrieved will the FO tree be properly built, with implicit
columns creation, border resolution, etc. (see

Exactly what I was thinking...

I too haven't looked very closely at Vincent's changes, but he did
manage to implement something that up to now, I have only speculated to
be possible, so I am VERY interested ;-)

There is already one certainty that should make things much more
straightforward here:
 fo:tables in retrieved fo:markers can, by definition, not have any

Since, as I recall, it should be possible to resolve/collapse /all/
borders in a table in the FO Tree, provided it does not span multiple
pages, I wouldn't suspect any problems here.

Well, even if the table spans multiple pages, IIC. See the javadoc of
fo.flow.table.ConditionalBorder and please tell me if there is anything
unclear. I’ll try to improve the code readability later on.

Borders are also not inherited

They are, in one case: when using the "inherit" keyword.

... and this should be graciously handled by the deferral of all property resolution for marker-descendants.

<snip />



Reply via email to