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
fo.flow.RetrieveMarker#cloneSingleNode).
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
page-breaks.
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 />
Cheers
Andreas
