A question where I'm more at home than with the FO tree... :-) On 26.08.2005 13:22:58 Luca Furini wrote: > 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).
Nasty one, but it was bound to surface one day. :-( > 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. It only easy if you have enough stretch and shrink available, right? > 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. The question I'm asking myself is if the layout might be badly affected by adjustments. If I get you right, the paragraph is not being rebroken after the adjustment, since it stores the stuff in LineBreakPositions. And even if it is rebroken, it can happen that you get one line break more or less. > 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; I'd be very reluctant here because of the potential impact on the GC. On the other side, the link to the LM could be reset once the area is fully resolved. > 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!) ... I like 2) better, too, but... > What do you think? Do someone see a different strategy? Two/Multi-pass rendering comes to mind again. I think this is a question of quality requirements. For most use cases it will be enough to simply try to squeeze the effective content into the available space, but it might not look optimal. For layout purists who don't mind about a 80-100% additional processing time a two-pass (or even multi-pass) approach might be better and also easier to implement. It would need to be configurable if we implement both variants. Jeremias Maerki