There is a layout problem with fo:page-number and fo:page-number-citation, already pointed out but still unresolved.

I think, these formatting objects are very similar, even if their actual handling is quite different: they both must be replaced by an information (a page number) that is (or could be) not available during the line breaking, so that a "provisional" width is used instead of the "real" one during the creation of the elements.

The method PageNumberCitationLM.get() allocates the width of the string "MMM" if the id is not already known; PageNumberLM.get() calls getCurrentPV().getPageNumberString(), but, as pagination is performed later, it always get the page-sequence initial page number (I am going to add a testcase showing a situation in which this makes some text overlap).

The real number could be known as soon as the pagination for the current page-sequence is done (for a fo:page-number) or even later (if there is a fo:page-number-citation whose referenced object is in a page-sequence following the current one). In both cases, if there is a differnce between the allocated width and the real one, indents and / or adjustment ratios should be re-computed.

The computation, in itself, is easy, as the LineLM already has all the necessary information: line width, unadjusted width, available stretch and shrink.

The point is that this information is stored in the LineBreakPositions, while the actual value (and the actual width) is set directly into the area tree.

In order to adjust the inline content of a line when the page number is resolved, I see two alternative strategies:

1) the LineLM has to handle this: this needs the LineAreas to hold a reference to the LineLM that creates them, and that knows all the needed information;

2) the LineArea has to handle this: this means that the LineArea (and the InlineAreas too) must be given the information about MinOptMax ipd and
provisional adjust ratio

I don't like 1 very much, because I think the creator LM is not a significant attribute of an area, but 2 involves adding many attributes too (and maybe even less significant!) ...

What do you think? Do someone see a different strategy?


Reply via email to