It just occurred to me that as an alternative we could simply track all XSL-FO IDs unconditionally. That would make scanning the SVG (or HTML or MathML) for links unnecessary. The overhead is probably even smaller and could actually have additional side-benefits for certain special use cases. For example, we could have an event that notifies the FOP-User which ID has its first (and last) area on which page. The area tree (and AT XML) size would increase a bit but I don't think by much (String plus PageViewport reference per destination).
On 03.09.2008 09:35:52 Jeremias Maerki wrote: > Hmm, you're right. This is more complicated that I thought. Getting the > actual position of a link destination on a page is easily done with > information from PDFRenderer. But to know the actual page of the link > destionation requires the registration of the ID as an item of interest > at layout time. For basic-link this is a single INTERNAL_DESTINATION > trait that is set on the area tree object, resolved by a LinkResolver. > For an SVG, however, only a single area is created and you might have > multiple links from the SVG into areas created from XSL-FO. This would > require something slightly different from a LinkResolver, plus you'd > need to scan the SVG at layout time for any links into XSL-FO so their > page number is resolved during layout. That needs some additional > infrastructure (both Java classes and area tree XML). This should > probably be done by extending Image and ForeignObject (in the area > package) from a common superclass which can take a list of link > destinations. The LinkResolver probably can't be used for this, but > fortunately, it's just a matter of creating another Resolvable and > making sure it is used. > > So in all, not trivial at all, but this could actually be used later > should anyone ever plug in (X)HTML support into FOP, too. Or JEuclid > could use something like that for XLinks in MathML back into XSL-FO. > > Maybe that helps. I hope I didn't scare you too much. > > On 02.09.2008 23:31:57 Stefan Bund wrote: > > Replying to my own post since I have gotten a little bit further. > > > > Implementing internal links seems to be more complicated than I had > > expected. As far as I understand, internal links are resolved within > > the area tree before the tree is rendered. An (external) SVG image > > resource howvever is only parsed at the render stage. > > > > However, I could get further if I could access the AreaTreeManager > > (and thereby its IdTracker) from the PDFANode. However, I could not > > find any way to get there (I have the PDFGraphics2D object and I can > > get the PDFDocument or RendererContext but I could not find a > > reference to the AreaTreeManager anywhere). > > > > I know, this is probably not the correct way to do this (I would need > > to somehow create a LinkResolver for every link in the SVG file while > > creating the area tree but at the moment that is way over my head). I > > hope, I can resolve the id's by just querying the IdTracker. This will > > possibly only work when the id is referenced from some other place, > > but it would be a start. > > > > Any pointer how to proceed? > > > > And maybe I got everything completely wrong. If so, could someone > > please set me right? > > > > stefan. > > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
