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

- 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 ...


Reply via email to