Jeremias Maerki <[EMAIL PROTECTED]> writes: > I don't think you should access the AreaTreeManager. The renderers are > designed to be passive. I believe the Renderer should be informed by the > AreaTreeHandler about any IDs it's managing. Not the other way around. [...] > Good luck!
I hope, I've had that. I have a patch which works for the very simple rudimentary test cases I've thrown at it. It is very likely missing something but for now it's much better than nothing IMHO. Here what I've done: I extended PDFGraphics2D to hold a reference to the PDFRenderer. I added a method 'renderInternalLink(Rectangle2D rect, String idRef)' to PDFRenderer which is really just an excerpt from 'renderInlineParent'. And here's the crux: renderInternalLink does ONLY take the idRef NOT the pvKey as an argument. I had this idea while looking over the implementation for 'PDFRenderer.getPDFGoToForID'. There I got the impression, that I might possibly just set pvKey to be null: The PDFGoTo would be incomplete and be added to unfinishedGoTos. To be later completed and added to the trailer. PDFGraphics2D got a member 'addInternalLink' akin to 'addLink' and I extended PDFANode to call 'addInternalLink' when the link target starts with '#'. I had to commented in a disabled piece of code in 'PDFRenderer.saveAbsolutePosition' so the missing pageRefs are set correctly for backward links. But then: Voila: It works ! Very possibly, it will only work if some other internal link to the same target exists (my first checks indicate, it works even if this is not the case), but that's no problem for me right now. Possibly, the PDF is not as efficient as it could be since ALL links from SVG's need to be added to the PDF trailer (as far as I understand it, I really don't know much about PDF internals) not only forward links. But again this is not a problem for me either, at least not at the moment. So I have come a long way. Next steps would be: - Check more cases - Test more thoroughly what happens if referencing a link target from SVG which is referenced nowhere else - Maybe the PDFRenderer can be optimized to reduce some of the overhead added through the use of incomplete links, especially backward links (we'd just need to add a cache for all encountered link targets and add those targets when first referenced, something like that. For backward links, I don't think an optimization is possible) - Possibly make this complete behavior user configurable I don't know, how much more time I can invest. I'd very much like working SVG internal link support is added to the trunk so later Versions will support it. But there is probably quite some work before this can be added and I don't have enough experience with Apache-FOP (say: almost none, I only started using it a few days ago) to go much further. I can happily hack on the code but I have no idea, whether the stuff I'm doing is good or perverse ;-) So, if batik could generate HTML image-maps I could convert my DocBook to PDF and HTML and have active links everywhere, but that's another story ... stefan.
