This patch adds support for internal PDF links to included SVG graphics. A link with a target '#<id>' will be resolved to point to the object with the given target id in the PDF. Limitations/shortcomings at the moment are: * Implemented at the renderer stage not the area stage and such only supported for PDF output * Resolving the links could certainly be optimized * The active area will always be rectangular (object bounding box) * I have only a few days of experience with Apahche-FOP and such there will probably some other shortcomings or missunderstandings. See the mailing list thread 'Re: Links in SVGs included into PDFs' started at Tue, 02 Sep 2008 11:02:48 +0200 on fop-users and continued later on fop-dev. (Thread at gmane: http://thread.gmane.org/gmane.text.xml.fop.user/26778)
Created attachment 22538 [details] patch against r693020 fop trunk
Hi Stefan, I am pretty busy at the moment but I have just taken a quick look at your patch without trying it out. My first thoughts are to remove the PDFGraphics2D dependency on the PDFRenderer. You should be able to just use the PDFDocument member variable to create a PDFFactory and then call makeLink() to make an internal link and then use a PDFRendererContext to get the currentPage object so you are able to call addAnnotation() from within the PDFGraphics2D implementation. It would be great if you could revise your patch a little. Hope this makes sense :). Adrian.
My problem is, I have absolutely no experience with Apache-FOP, so atm, everything you try to explain is chinese to me. The other problem is, I just got a new project and will be busy working on that ... OTOH, I'd love to get the patch into shape. Maybe further discussion on this should move again to the thread on senf-dev since I'd have to ask some more questions on how Apache-FOP works ...
Created attachment 22576 [details] Counter-proposal (incomplete) As Adrian noticed, PDFGraphics2D must not have a dependency on PDFRenderer since this class is also used in the PDFTranscoder (for SVG to PDF rendering) where there is no PDFRenderer instance. That's indirectly what I meant by subclassing the PDFAElementBridge and PDFANode. I've create a counter-proposal for this which moves the link generation into the PDFSVGHandler which is used by the PDFRenderer to create in-page SVGs. Parts of the patch are still from your original patch. What's still missing here is a clean way to track the locations of all FOs with an ID as discussed already. This should really be possible without creating a destination object for each such ID. I hope this helps to bring this further.
Created attachment 22577 [details] "link-back" example (SVG link links back into parent XSL-FO)
Created attachment 22676 [details] The cut text is highlighted with a red sphere
Please ignore the new attatchement. Wrong bug.
resetting P2 open bugs to P3 pending further review
increase priority for bugs with a patch