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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED ------- Additional Comments From [EMAIL PROTECTED] 2007-04-30 06:16 ------- (In reply to comment #3) > 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. You're right. Looks like I clicked too quickly through the "apply patch" dialog. <snip/> > > 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. Well, that's me not being able to catch up with everything lately. :-( I get the impression that it should be possible to do this without breaking backwards-compatibility too much. Maybe we should do an inventory of people who are maintaining external renderers so we have an idea who would be affected and how much. > > 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. I'm in no position to "want" anything. :-) I can only make wishes and be happy that there are people around helping us out. But consider the removal of the idfirsts attribute a wish. *g* Since I'll be leaving for ApacheCon in a few hours I may not have enough time to finish applying the current patch. If you could look into the issue until the end of the week that'd be awesome. But don't worry if you don't make it. BTW, another wish if I may: Would you please submit an ICLA (and CCLA if necessary) [2]? Your patch is a borderline case where an ICLA on file becomes necessary. Thanks a lot! You can submit the document by fax or by sending a scanned version to BOTH secretary.at.apache.org AND legal-archive.at.apache.org. [2] http://www.apache.org/licenses/#clas -- 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.