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.

Reply via email to