Some ID cannot be resolved by fo:page-number-citation-last With FOP-trunk_svn689406 WARN: Page 1: Unresolved ID reference "space-after" found. WARN: Page 1: Unresolved ID reference "margin-bottom" found. WARN: Page 1: Unresolved ID reference "margin" found. WARN: Page 1: Unresolved ID reference "padding" found. WARN: Page 1: Unresolved ID reference "padding-bottom" found. With FOP 0.95: WARN: Page 1: Unresolved id reference "inline" found.
Created attachment 22490 [details] For testing Testing file that generates those warning messages
Created attachment 22492 [details] Test file with several pages for each ID The preceding test has one page for each ID (PNC=PNCL) In this test page breaks have been added in each element with ID, so PNCL is different from PNC The result is NOT correct: With FOP-trunk_svn689406 NO ID is resolved With FOP-0.95 IDs are resolved but PNCL is wrong (equals to PNC)
Thanks for the report and the testcases. Strange, I cannot immediately see the problem... Comparing to our existing testcases, the only notable difference is the presence of the forced breaks. I wonder whether that's somehow throwing the ID resolution off-track somewhere. It is definitely not because the IDs aren't registered, as I can see from the debug output. It's simply the resolution step that is skipped. Even stranger, in my local sandbox, there is one set of IDs correctly resolved: those of the page-sequences. All the others still remain unresolved. If that doesn't happen in your case, I guess I'll also have to look to add that change for page-sequences to FOP Trunk. Adding a second table of contents after the main page-sequence shows all the page-number-citation correctly resolved, but not the page-number-citation-last. Under investigation...
Just confirmed that it is definitely the presence of break-before and break-after that causes the ID resolution to be skipped (hence why I'm changing the bug summary description). If you remove those from the example, and change the blocks to have some arbitrary content that causes implicit page-breaks, all IDs are resolved nicely. (see the added attachment)
Created attachment 22501 [details] Test file showing that the removal of the forced breaks leads to normal resolution
Some additional info: using only break-before on the innermost blocks does not seem to disturb the id-resolution either. Notable other issue, though: forced breaks on the first block in the main page sequence (= blocks nested in the inline) do not seem to be processed correctly. The following pattern does lead to correct id-resolution, and seems to lead to the same output: <block id="..." break-after="page"> <block>first page</block> <block break-before="page">continue</block> <block break-before="page">continue</block> </block>
... and some more: the following also works like a charm <block id="..."> <block>first page</block> <block break-before="page">continue</block> <block break-before="page" break-after="page">continue</block> test dummy text </block> It seems that there's no problem, except for the case where the last inner block has break-after, and no more content follows.
In the meantime, I also studied the first example more closely, and there it's the space-after or margin/padding-bottom causing the resolution to be skipped. The technical explanation is that, in FOP trunk, I made a change resulting notifyEndOfLayout() only being called if the last position is the last generated position by the LayoutManager. In case of forced breaks and/or space-after, additional positions are generated that are not visible anymore to the PositionIterator in addAreas(), hence why the isLast() condition returns false in those cases. notifyEndOfLayout() is never called for those blocks, so the page-number-citation-last never gets resolved.
For the break-after case, I got it working by not wrapping the Position corresponding to the BreakElement. see the partial fix committed here: http://svn.apache.org/viewvc?rev=690532&view=rev Leaving the bug open, due to the remaining issue with space-after, margin-bottom and padding-bottom. A similar tactic could work there. Instead of wrapping the positions, simply add the elements to the returnList for the parentLM (?) In that case, the last position in the sequence addAreas() iterates over, will be the last position generated by the LM. Otherwise, that would be the SpaceElement or BorderOrPaddingElement that is passed upward from the child...
(In reply to comment #3) > Even stranger, in my local sandbox, there is one set of IDs correctly resolved: > those of the page-sequences. All the others still remain unresolved. If that > doesn't happen in your case, I guess I'll also have to look to add that change > for page-sequences to FOP Trunk. > No problem with ID of page-sequences, IDs are correctly resolved
resetting P2 open bugs to P3 pending further review
change status from ASSIGNED to NEW for consistency