Hi,
we use Prince-XML on HTML that is generated by an XSLT and that contains many links. Most links become bookmarks in the generated PDF just fine, but there is a certain set of links that never becomes a bookmark. In those cases, the link text is generated correctly in the PDF, but it seems to be normal text, not a bookmark. I also tried the area around the link text, in case the area of the bookmark is generated differs a bit from the area where the link text is shown, but no success.
In the HTML file, using any of a number of browsers (FF, IE, Opera, Safari) these links work just fine.
This problem is entirely repeatable and I verified that it happens with all Prince-XML versions I tried: 8.0, 8.1r5, and 9.0r4.
It turns out that in all cases that don't work, the link targets a named anchor, i.e. an "A" element that has a "NAME" attribute. In those cases that work, the link targets an element (e.g. "H4") with an "ID" attribute.
Because the links can be fairly long (e.g. "#HG-A-EnabledLogicalElement-O-AssociatorNames-A-ElementCapabilities"), I have added support to the (quite extensive) Javascript that is embedded in the HTML to change the links to a shorter hashed value (e.g. "#HASH-0123456789-0"), but that did not solve the problem.
The reason I am using named anchors for some links is that the same target (a heading) needs to be targetable using multiple different names, to keep the complexity of the XSLT manageable.
For now, my questions are:
-> Is linking to named anchors supposed to be supported by Prince-XML?
-> Is there a length limitation for link names in Prince-XML?
I have attached a linkproblem.zip file containing the HTML and PDF that does not work. The files in that archive are:
runprince.bat - command line for invoking Prince
DSP1080_2.0.0a.html - input to Prince, self-contained (with embedded Javascript, CSS, images)
DSP1080_2.0.0a.pdf - output from Prince 9.0r4
DSP1080_2.0.0a.jsdone.html - input, with Javascript expanded by Firefox (using its "Save As...")
Kind regards,
Andy
we use Prince-XML on HTML that is generated by an XSLT and that contains many links. Most links become bookmarks in the generated PDF just fine, but there is a certain set of links that never becomes a bookmark. In those cases, the link text is generated correctly in the PDF, but it seems to be normal text, not a bookmark. I also tried the area around the link text, in case the area of the bookmark is generated differs a bit from the area where the link text is shown, but no success.
In the HTML file, using any of a number of browsers (FF, IE, Opera, Safari) these links work just fine.
This problem is entirely repeatable and I verified that it happens with all Prince-XML versions I tried: 8.0, 8.1r5, and 9.0r4.
It turns out that in all cases that don't work, the link targets a named anchor, i.e. an "A" element that has a "NAME" attribute. In those cases that work, the link targets an element (e.g. "H4") with an "ID" attribute.
Because the links can be fairly long (e.g. "#HG-A-EnabledLogicalElement-O-AssociatorNames-A-ElementCapabilities"), I have added support to the (quite extensive) Javascript that is embedded in the HTML to change the links to a shorter hashed value (e.g. "#HASH-0123456789-0"), but that did not solve the problem.
The reason I am using named anchors for some links is that the same target (a heading) needs to be targetable using multiple different names, to keep the complexity of the XSLT manageable.
For now, my questions are:
-> Is linking to named anchors supposed to be supported by Prince-XML?
-> Is there a length limitation for link names in Prince-XML?
I have attached a linkproblem.zip file containing the HTML and PDF that does not work. The files in that archive are:
runprince.bat - command line for invoking Prince
DSP1080_2.0.0a.html - input to Prince, self-contained (with embedded Javascript, CSS, images)
DSP1080_2.0.0a.pdf - output from Prince 9.0r4
DSP1080_2.0.0a.jsdone.html - input, with Javascript expanded by Firefox (using its "Save As...")
Kind regards,
Andy