PDF with SVGs: Link from text in SVG to text in the PDF?

[mtsurikov]

Imagine a set of DITA content that includes SVGs and that all gets published to a PDF.

We know that DITA-OT natively supports links (via xref elements) within text content. So, for example, in topicA.dita, would yield a clickable link to topicB.dita.

Is it possible to do this linking from an SVG? For example, can I link to topicB.dita from within a text line in the SVG?

[jelovirt]

Technically it's possible to make it work, but DITA-OT doesn't support this. One of the problems with this type of link is that SVG uses a HTML-like URL, which is file.ext#fragment-id where as DITA uses URLs like file.ext#topic-id/element-id. One solution would be that links in SVG that target DITA topics, will use DITA's file.ext#topic-id/element-id. Then it would be possible to rewrite the links during PDF processing to target content from DITA.

This is unlikely to be implemented by the current DITA-OT dev team as a built-in feature, but it can be done as a plug-in.

[mtsurikov]

Thank you, @jelovirt , for your incredibly fast response!

I know that, in standard DITA, it's possible to link to a topic without an element ID, like this:

< xref href="topicA.dita" / >

I believe you are saying that if I embed this type of syntax in an SVG:

< a href="topicA.dita#topic-id/element-id" > Click here< /a >
or perhaps
< a href="file:///topicA.dita#topic-id/element-id" > Click here < /a>

the link would work... right?

[mtsurikov]

Interim update to anyone reading this discussion: I've now conducted enough experiments to determine that neither of these works in SVGs:

< a href="topicA.dita#topic-id/element-id" > Click here< /a >
< a href="file:///topicA.dita#topic-id/element-id" > Click here < /a>

That made sense to me after I realized that the SVG processing isn't aware of file names outside of the SVG itself, and those file names disappear during DITA-to-PDF processing anyway. (That processing gathers all topics into one file.)

[raducoravu]

How about if you use DITA XML image maps and define the link underneath the image reference? Oxygen's DITA to PDF using CSS publishing has support for creating the hotspots over the published SVG file, not sure about the classic XSL-FO based PDF.

[mtsurikov]

That is a really creative idea, @raducoravu . Thank you!

I'm using XSL-FO, not CSS, so I can't create the exact image maps that you suggested. However, your idea led me to another one involving named destinations. On a whim, I added this to one of my SVGs:

< a xlink:href="#page=3" >
< rect x="0" y="0" width="200" height="200" fill="transparent" stroke="blue" stroke-width="2"/ >
< /a >
< a xlink:href="https://www.utexas.edu" >
< circle cx="250" cy="250" r="50" fill="transparent" stroke="red" stroke-width="2"/ >
< /a >

to test the hyperlink possibilities. The first < a > element -- over a rectangle -- is intended to jump to a named destination in the PDF. As long as I create -- manually or otherwise! -- a named destination called page=3, I can click on the rectangle and it takes me to that destination. The second < a > element -- over a circle -- is just to test true Web hyperlinking. It also works.

I also discovered that the attribute of the < a > element must indeed be xlink:href, even though that's apparently deprecated. The new equivalent attribute, href, does not work.

So now I just need to find how to created PDF named destinations programmatically in my custom DITA-OT plug-in! Apache FOP can allegedly do that, but I haven't been able to make it do that. (So I created https://issues.apache.org/jira/browse/FOP-3263 . )

[kirkilj]

Hi Michael, if you're using FOP, you can use one of their extensions for anchors/internal destinations: https://xmlgraphics.apache.org/fop/2.11/extensions.html.

Anchors or Named Destinations
Use the fox:destination element to define "named destinations" inside a PDF document. These are useful as fragment identifiers, e.g. "http://server/document.pdf#anchor-name". fox:destination elements can be placed almost anywhere in the fo document, including a child of root, a block-level element, or an inline-level element. For the destination to actually work, it must correspond to an "id" attribute on some fo element within the document. In other words, the "id" attribute actually creates the "view" within the PDF document. The fox:destination simply gives that view an independent name.

<fox:destination internal-destination="table-of-contents"/>
...
<fo:block id="table-of-contents">Table of Contents</fo:block>

I haven't used it, but it sounds like this should put the anchors into the DITA-sourced topics within the PDFs that you can target from the SVG objects.

Your plugin would need to inject the fox:destination elements depending on what template matches you want to use.

[mtsurikov]

Thanks, @kirkilj . And hi after a very long time!

Yes, that's exactly the extension I wanted to use, and could not get to work. When Apache FOP encounters < fox:destination > and < fo:block id = ... >, it does not actually produce named destinations in the PDF. That's why I created https://issues.apache.org/jira/browse/FOP-3263 .

[kirkilj]

FWIW, I added my vote to the FOP ticket.