You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Stefan Bund <as...@gmx.de> on 2008/09/02 11:02:48 UTC
Links in SVGs included into PDFs
Hi all,
I am very new to fop, I'm really coming from docbook (which I'm
relatively new to also ;-) ). I have a question regarding links (svg:a
tags) in graphics included into fo documents via
fo:external-graphic. When rendering to PDF, I don't seem to get the
links.
While googling around, I got the impression, that fop supports SVG
links. Hoewver, I could not find a concrete working example from which
to start.
My question is: How do I get this to work? I know, this is a very
general question but it's hard for me to be more specific since I'm so
new to the subject.
I would be very grateful for any pointer,
stefan.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Links in SVGs included into PDFs
Posted by Stefan Bund <as...@gmx.de>.
I have created a bug-report on bugzilla. Tse ID is #45759
https://issues.apache.org/bugzilla/show_bug.cgi?id=45759
stefan.
Re: Links in SVGs included into PDFs
Posted by Stefan Bund <as...@gmx.de>.
Andreas Delmelle <an...@telenet.be> writes:
> From what you have described, it seems to be a valid approach, but
> without looking at the actual code, it's still an impression only...
>
> The only thing I'm slightly concerned with is that the proposed
> solution would only work for PDF output (not for the AWT preview
> panel, for example).
Thats right. You have me there. On the other hand, a solution working
across all output formats would still need adjustments within each
output format as far as I understand (In that formats PDF
renderer). Since links are stored as annotations in the inline parent
(whatever that really is ;-) ) and it's only possible to store a
single link there which always covers the complete object the area
tree would have to be extended to support svg links. So the renderers
would have to be extended all to support this extension ... of course
this would be much better as a solution since it would allow to
implement links from other graphical formats as well.
On the other hand, that solution is hugely more complex to implement,
at least for me ...
> However, since it is by far the most popular output format, this is
> not really a big issue. Supporting it for one format is still a lot
> better than nothing at all. :-)
That's my impression to. I'm coming from docbook, so now it works for
docbook->pdf. The next step on that front would be, to get graphical
links to work in docbooks HTML output using image maps. But that has
nothing to do with Apache-FOP.
> (... snip very helpful area-tree / resolvable explpanation ...)
>
> As such, you don't need them, if you can resolve the links in the SVG
> entirely at the rendering stage. As Jeremias did mention, if you need
> to track them from the layoutengine (in which case the page they
> point to may not exist yet in the area tree) then you would need a
> Resolvable implementation to make sure the resolution is triggered
> automatically when the corresponding 'id' is encountered on a
> following page.
Ahhh ... ok. I get it. Since the PDF output engine can work with
unresolved links by placing something in the PDF trailer, the PDF
renderer does not rely on links being reolved in the area tree.
However, other output formats may have a problem with this, ok.
> Indeed. Upon adding a new attachment, you can mark the earlier version
> as 'obsolete'.
Ah, ok. I'll post the bugzilla ID here when I have uploaded the code.
stefan.
Re: Links in SVGs included into PDFs
Posted by Andreas Delmelle <an...@telenet.be>.
On Sep 4, 2008, at 10:03, Stefan Bund wrote:
> Andreas Delmelle <an...@telenet.be> writes:
>> Seems like a nice job you did here!
>
> Thanks. Do you know, wether my assumptions are valid ? I've been
> guessing my way along and it would be nice for someone in the know to
> check up on the code.
From what you have described, it seems to be a valid approach, but
without looking at the actual code, it's still an impression only...
The only thing I'm slightly concerned with is that the proposed
solution would only work for PDF output (not for the AWT preview
panel, for example).
However, since it is by far the most popular output format, this is
not really a big issue. Supporting it for one format is still a lot
better than nothing at all. :-)
> The quesetion is, how to make the code
> available.
As I hinted, creating an 'svn diff' of the altered/added files, and
attaching it to a Bugzilla entry (https://issues.apache.org/bugzilla)
is the preferred option.
> What I don't understand is, how the linking stuff in the renderers
> integrates with the Resolvable stuff in the area tree. I do not add
> any resolvables in the area tree for the SVG images.
The area tree is created by the layoutengine. When an area has to be
generated for a FO node that references another node by its
'id' (like a basic-link, or a page-number-citation), and the 'id' it
points to has not yet been associated to a previous page-viewport, a
Resolvable is created and added to the IdTracker. Upon generating an
area for a FO node with a given 'id', a check is performed to see if
any Resolvables exist that reference it. If the 'id' was already
added to a previous page, we don't need a Resolvable, as we can
immediately get the information we need.
As such, you don't need them, if you can resolve the links in the SVG
entirely at the rendering stage. As Jeremias did mention, if you need
to track them from the layoutengine (in which case the page they
point to may not exist yet in the area tree) then you would need a
Resolvable implementation to make sure the resolution is triggered
automatically when the corresponding 'id' is encountered on a
following page.
>
>> If you like, you can already open a Bugzilla entry for this, and
>> attach a diff against FOP Trunk there.
>
> No problem. Only, what should I do when I later change the code
> further? Followup on the Bugzilla entry with a new patch ?
Indeed. Upon adding a new attachment, you can mark the earlier
version as 'obsolete'.
Cheers
Andreas
Re: Links in SVGs included into PDFs
Posted by Stefan Bund <as...@gmx.de>.
Andreas Delmelle <an...@telenet.be> writes:
> Seems like a nice job you did here!
Thanks. Do you know, wether my assumptions are valid ? I've been
guessing my way along and it would be nice for someone in the know to
check up on the code. The quesetion is, how to make the code
available.
What I don't understand is, how the linking stuff in the renderers
integrates with the Resolvable stuff in the area tree. I do not add
any resolvables in the area tree for the SVG images.
> If you like, you can already open a Bugzilla entry for this, and
> attach a diff against FOP Trunk there.
No problem. Only, what should I do when I later change the code
further? Followup on the Bugzilla entry with a new patch ?
> This makes it more probable that someone else picks it up (in case
> you're really unsure when you'll be able to work on it further).
stefan.
Re: Links in SVGs included into PDFs
Posted by Andreas Delmelle <an...@telenet.be>.
On Sep 3, 2008, at 15:51, Stefan Bund wrote:
Hi Stefan
> <snip />
Seems like a nice job you did here!
> 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 ;-)
If you like, you can already open a Bugzilla entry for this, and
attach a diff against FOP Trunk there.
This makes it more probable that someone else picks it up (in case
you're really unsure when you'll be able to work on it further).
Cheers
Andreas
Re: Links in SVGs included into PDFs
Posted by Stefan Bund <as...@gmx.de>.
Jeremias Maerki <de...@jeremias-maerki.ch> 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
possible)
- 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 ...
stefan.
Re: Links in SVGs included into PDFs
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <de...@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
Re: Links in SVGs included into PDFs
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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 <de...@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
Re: Links in SVGs included into PDFs
Posted by Stefan Bund <as...@gmx.de>.
Jeremias Maerki <de...@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 ...
> 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.
>> 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.
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 :-)
stefan.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Links in SVGs included into PDFs
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Links in SVGs included into PDFs
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Links in SVGs included into PDFs
Posted by Stefan Bund <as...@gmx.de>.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Links in SVGs included into PDFs
Posted by Stefan Bund <as...@gmx.de>.
Jeremias Maerki <de...@jeremias-maerki.ch> writes:
> Links in SVG are supported but only to external destinations, i.e.
> external URLs. Support for internal destinations from SVG back into the
> parent FO document hasn't been implemented, yet.
I had problems even with internal URL's until I found out I wasn't
running the current stable of fop (which I had installed into my home
dir) but the system version (which is ancient) ... duh ...
> To implement this, I think a special PDFAElementBridge would be needed
> which is aware of the FO IDs and their location. This would have to be
> plugged into the PDFSVGHandler. Not sure how difficult this would be to
> implement, but it can't be that hard. Want to try? I can probably give
> you a few more pointers if you want.
I'd love to try but at the moment I shouldn't take the time for
this. However, a workflow which allows to produce nice PDF's with
embedded graphics which support links is exactly what I need at the
moment. So maybe I will take a look .. I'm crazy enough to be
interested ;-). I'll check out the source and try to grok something
:-)
The Problem is, that I really have no idea, how FO really works. On
the other hand, I probably don't need to. Since external URL's are
already implemented, it really should not be very difficult since
internal links are also implemented albeit not for SVG. So I probably
could take that code and somehow adapt it to work with SVG's ... at
least I could try.
So if you can give me a pointer, I'll listen. I can't promise to be
able to contribute something though.
stefan.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Links in SVGs included into PDFs
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Links in SVG are supported but only to external destinations, i.e.
external URLs. Support for internal destinations from SVG back into the
parent FO document hasn't been implemented, yet.
To implement this, I think a special PDFAElementBridge would be needed
which is aware of the FO IDs and their location. This would have to be
plugged into the PDFSVGHandler. Not sure how difficult this would be to
implement, but it can't be that hard. Want to try? I can probably give
you a few more pointers if you want.
On 02.09.2008 11:02:48 Stefan Bund wrote:
> Hi all,
>
> I am very new to fop, I'm really coming from docbook (which I'm
> relatively new to also ;-) ). I have a question regarding links (svg:a
> tags) in graphics included into fo documents via
> fo:external-graphic. When rendering to PDF, I don't seem to get the
> links.
>
> While googling around, I got the impression, that fop supports SVG
> links. Hoewver, I could not find a concrete working example from which
> to start.
>
> My question is: How do I get this to work? I know, this is a very
> general question but it's hard for me to be more specific since I'm so
> new to the subject.
>
> I would be very grateful for any pointer,
>
> stefan.
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org