On Oct 22, 2007, at 18:30, Andreas L Delmelle wrote:
Etc. My question: why is a special treatment needed when a table is
found as a descendent of a marker? My understanding is that if a
whole
table is defined in a marker, then it doesn’t depend on the enclosing
table in which the marker is retrieved. Or have I completely missed
something?
Small detail: property parsing is only done for descendants of
markers if and when the marker is retrieved. This test was added to
make sure that implicit column-numbers are only computed once for
table-cells and -columns that are marker-descendants. (IIRC, I did
so in response to a bug-report).
If the marker in which the table appears is never retrieved, then
we don't even bother to pass through the parser, and simply store
the explicitly specified properties as name/value pairs.
Note that the same goes for white-space handling (see
FObjMixed.addChildNode()). This is also bypassed for descendants of
fo:markers, since in fo-tree context, nothing is known about the
'ancestor' block (which will actually be an ancestor of the
fo:retrieve-marker).
Before I had my way with markers, there were numerous bugs/errors,
amongst others in white-space handling, percentage-resolution and
property inheritance. That's precisely why I decided at that time to
simply defer any property-resolution for marker-descendants to
RetrieveMarker.cloneFromMarker() (which is only called later in the
process, in response to PageSequenceLM.resolveRetrieveMarker()).
Cheers
Andreas
