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

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()).



Reply via email to