woolly wrote: <snip/>
Fop reads in the fo source and creates an area tree from it. Whilst the area tree is being created, PageNumberCitationLayoutManager.getPageNumberCitationInlineArea(LayoutManager parentLM) is used to generate InlineAreas. In this method, if the page number is known, a TextArea is returned with the proper number, otherwise an UnresolvedPageNumber containing the string "MMM" is returned (UnresolvedPageNumber is a TextArea subclass). More processing happens, all layout adjustments are made (I think this happens in AbstractBreaker.doLayout()) Towards the end of creating the area tree, page-number-citations are resolved through AreaTreeHandler.tryIDResolution() Hence, the page numbers were "MMM" when all the layout was being done, but are later changed to the correct number without any further layout change. The problem seems to be that as the area tree is being created, a page is laid out after each one is created, when really, the layout should come at the end after all pages (and hence page-number-citation references) are known.
I think your assesment is okay so far. Although IIUC your suggested "fix" will cause many other problems. The approach that was adopted in 0.20.x was to do a minor correction on lines containing the page-number-citation at the same point as AreaTreeHandler.tryIDResolution is called. By minor correction I mean altering the word spacing on the line to compensate for the different width of the page number. Whilst this is a sub optimal solution it is prefarable to your solution or a solution involving two layout passes.
Just my 2 cents, Chris
