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=42067>. 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=42067 ------- Additional Comments From [EMAIL PROTECTED] 2007-04-30 05:35 ------- Hi Jeremias, > Anyway, in my own tests and your patch locally applied, none of the > GoTo Actions get properly positioned since PageViewport.setFirstWithID() > is never called (except from the AreaTreeParser which is only active in > special environments. It's also called from AreaTreeHandler.associateIDWithPageViewport (near the top of the patch file). Maybe this didn't make it into your source because there are several conflicts with a more recent commit. They're all trivial though; easy to resolve. > I'm wondering if it weren't simpler just to track "first IDs" inside > PDFRenderer only, i.e. whenever an area with an ID is encountered its > position is recorded. If later the same ID is recorded but from a page > logically before the earlier page (out-of-order rendering), the position > would be overwritten. Yes, this was one of the options I presented on fop-dev while I was working on this. It would make PDFRenderer more complicated, but you could kick the entire link resolution stuff out of the layout code (PV, ATH), so overall the code would become simpler. The problem is that this would break other (custom) renderers that expect the INTERNAL_LINK trait to contain the target PV key. > It could possibly also remove the necessity to extend the area tree XML > format with the "idfirsts" trait. Just a thought. I take it you don't like that attribute. Neither do I. It's ugly, and every time I look at it I get the feeling that it shouldn't be necessary. But it was the best I could come up with given the chosen approach (= resolve to page level in layout phase, determine exact location in renderer). There's a workaround possible though (in PDFRenderer): store the first occurrence of each ID on every PV in a map (with the ID as key, and a list of PV->location maps as value). Whenever an internal link trait is parsed, the ID plus the key of the first PV containing that ID are extracted. At that moment, if the location of that ID on that PV is already in the map, the resolution can be completed. If not, it'll have to wait (but this is also the case in the current patch). The renderer wouldn't even have to worry about which page comes first, because the link trait already contains that information. If you want me to implement this, I will. -- 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.
