xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Links in SVGs included into PDFs
Date Wed, 03 Sep 2008 08:26:38 GMT
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 <dev@jeremias-maerki.ch> 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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Mime
View raw message