Reporting Module Hyperlink in Object

I am experiencing an issue with hyperlinking in the Reporting Module. I would like the images in my report to link to their full-size versions, which are hosted on Webdev. However, when I enter a URL into the URL field, such as as an example, it seems that the link is embedded in the PDF but is not functioning as a clickable hyperlink.

Have found that clicking the link will return to page 1 regardless of what I put in the URL field. I can put Page:2 or Page:3 but when linking a URL it defaults back to page 1

Ignition Version: 8.1.32

I would expect the url to be more specific than that.

Something like

Do you have a sample PDF you're generating you can upload?

Here is a sample of the generated PDF

Report (6).pdf (300.0 KB)

In your export, it appears that you used 'bare' urls ( - some tools (Chrome, MacOS Finder, Safari) balk at this and either do nothing when the links are clicked, or reject it as invalid. Interestingly, Firefox's embedded PDF viewer seems to handle it fine.

If you use a fully qualified URL including the protocol (, it works for me in Finder, Safari and Firefox, but is silently rejected in Chrome; possibly as some sort of security measure since it's a local file trying to open an internet URL.

url 10-31-23 11AM.pdf (4.7 KB)

You can open the PDFs exported by the Reporting module in a text editor to confirm; there's lots of other junk you don't necessarily care about, but you should see sections like this somewhere:

/Type /Action
/URI (
/Type /Action
/URI (

I have tried with the full URL ( ) and it still does not open. I am trying in Adobe Acrobat and Chrome.

If I am on page 2 and click the link it jumps back to page 1.

So, if I manually add the link using a PDF editor, it works in Chrome and Adobe Acrobat. However, I've noticed that the PDF code generated by Ignition is in PDF 1.2 format, and after editing it with Adobe, it becomes PDF 1.6. Could this be the cause of my problem? Perhaps the older PDF version (1.2) doesn't support hyperlinks, and that's why they aren't functioning as expected.

<?xpacket end="w"?>
123 0 obj
129 0 obj

It would be really nice if this worked, but unfortunately the behavior is still the same in chrome and adobe. Looks like other applications have been able to generate URLs in a PDF without issue.