I have to call in sick today so this is my last message for now. Just to give you some feedback. BTW, I noticed this should move to fop-dev since we're discussion development. Please drop the fop-users CC in any follow-ups.
On 03.09.2008 10:00:59 Stefan Bund wrote: > Jeremias Maerki <[EMAIL PROTECTED]> writes: > > It just occurred to me that as an alternative we could simply track all > > XSL-FO IDs unconditionally. > > That was, what I was thinking about. As a very first step, I want to > implement just the Renderer part: Resolve the internal id references > if and only if they have been registered with the IdTracker already. > > If I have that, the next step is to get the target id's into the > IdTracker and it has already occured to me, why not just add all > id's, if that is not, what is already done (from your comments, it's > not). > > > That would make scanning the SVG (or HTML or MathML) for links > > unnecessary. > > Exactly. That would need an extension of Image and so on. I had > thought of giving Image (or a baseclass) a list of resolvables and > subclassing Image with a special SVGImage which would then do the > parsing and store the created SVG DOM Tree to be reused at render > time. > > However, this seems to be FAR more complicated then just registering > all id's ... Yes, and I wouldn't have like a SVG-specific solution. > > 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). > > Sounds reasonable :-) > > > 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. > > This is, where I am standing currently. My problem is getting exactly > that information. > > I can use PDFRenderer.getPDFGoToForID(targetID, pvKey), however, for > that I need to already know the pvKey. As far as I understand, I could > get that information form the IdTracker but after lot's of grepping > and reading through the source code I could not find a way to access > the AreaTreeManager from the PDFRenderer. > > So my question at the moment is: a) How do I get at the page viewport > key given an id or more specifically b) How do I access the > AreaTreeManager from PDFRenderer. 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. > >> Maybe that helps. I hope I didn't scare you too much. > > No, you have cleared up lots of points which I guessed but was way from > sure about. Cool. > I'd try to continue along the way assuming the register-all-id's stuff > could work. And even if that would NOT work (register-all-id's), I > think i would be MUCH farther ... as a last resort I can always hack > references into the surrounding code, if needed even using some xslt > to preprocess the fo+svg stuff (which is already generated from > docbook in my case so adding some more xslt is realtively straight > forward). Quite a hack and not a general solution but it could at > least work for the moment :-) and I'm at the point where I'd be > grateful for ANY working solution (I have not found ANY way to produce > a PDF file with embeded images containing links into the PDF ... that > is, using open source technology). > > Many thanks for all your insight. I feel, this could even lead > somewhere :-) Good luck! Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
