>----- Oorspronkelijk bericht -----
>Van: Manuel Mall [mailto:[EMAIL PROTECTED]
>Verzonden: donderdag, december 28, 2006 09:41 AM
>
>However, what about markers. Their content is only known at layout time
>isn't it?
Yes and no...
Yes, the definitive content is only known at the time the marker is retrieved.
Currently, markers are treated differently than other FOs in that:
a) properties are resolved
b) white-space handling is performed
only when the marker is retrieved (as part of the marker-subtree-cloning in
RetrieveMarker, which is performed during the layout-stage)
OTOH at any rate, the above may be a bit misleading, because by the time a
TextLM is instantiated for a marker's text-descendants, the definitive content
is known to the same extent as that of a 'regular' FO.
That is: all white-spaces that can be collapsed with certainty [without any
line-breaking context] will have been removed from the FOText's char array
before the corresponding TextLMs is created. All that remains to be done by the
LM is the possible white-space removal around formatter-generated linebreaks
(which the FObj is agnostic about).
If the problem were simply about FOTexts, then the solution could be rather
straightforward, roughly to get to the last character of the preceding FOText:
(in TextLM)
---
FOText precedingTextInBlock = this.foText.getPreviousFOTextThisBlock();
if (precedingTextInBlock != null) {
char lastPrecedingChar =
precedingTextInBlock.ca[precedingTextInBlock.ca.length - 1];
}
---
(don't have the sources at hand ATM, so will have to check for the correct
syntax)
But the fact that the FOText instance is null, does not yet guarantee that
there is no preceding node which needs to be taken into account. There could
still be an fo:character... In theory, such a node would also be reachable
through FONode.getParent() and FONode.getChildNodes() (which are both public
methods, so definitely accessible to the layoutmanagers)
Cheers,
Andreas
