DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39118>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39118 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From [EMAIL PROTECTED] 2006-04-23 09:41 ------- Pierre-Henri, I've applied your patch with modifications. See: http://svn.apache.org/viewcvs?rev=396243&view=rev Thanks a lot for that and sorry for the delay. I found a remaining problem with your patch. When a formatting object spans multiple pages, forward references are not properly resolved. You can see that in the *_basic.xml test case which I've modified and disabled. It looks like you didn't entirely get my hint last time. The problem is that addAreas() can be called multiple times. An example: If a block spans multiple pages, it is called once for each page it generates area for. Since you notify the AreaTreeHandler after each call to addAreas (and not only after the last) a forward reference gets the wrong page number (i.e. the one of the first area). Determining the last call to addAreas for a formatting objects might be a little tricky, however. Furthermore, you've only addressed block-level formatting objects and page-sequence for ID processing, but some of the inline-level formatting objects can similarly span multiple pages (like fo:inline for example). I don't think this is critical since you might rarely refer to an inline-level ID with page-number-citation-last. The most important use case is certainly referring to an ID from page-sequence to achieve reliable "page x of y" without the "empty block with ID" hack we've used until today. I'm leaving the issue open for now. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
