You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I have a process that pulls an embedded pdf from OBX.5 and stores it as an attachment. We have tested and used this process for years so we know that it is functioning properly.
Sometimes we do have an error whether it is network, data, or corruption. We then turn to a number of tools to assist us. One of those tools is the pdf viewer so we can see the PDF. Rarely the attachment viewer fails due to xref expected at start of table. I would say it works fine at least 85% of the time.
The error message in question makes little sense. But the xref is only required as of pdf reference up to version 3 which published in 2001. The next revision made it optional. So, the attachment view is trying to render a pdf using a 23 year old reference. I fully suspect my PDF is perfectly fine, but I cannot view it. We are not using a long term network archive where I can just drop a file with a filewriter. Instead this HL7 message is sending the pdf to our long term document storage solution.
This happens on dozens of documents.
To Reproduce
Attempt to view a PDF document stored as an attachment, certain perfectly fine pdfs will error.
Expected behavior
Actual behavior
I get an error about xref expected at the start of the table.
Environment (please complete the following information):
Mirth Appliance
Mirth Version 4.3
Java Version on the Appliance
Java7 1.7.0_151-b15
Java8 1.8.0_181-b13
Java OpenJDK 11+28
Workaround(s)
One can supposedly use network location to write a the attachment to a file and then use a different and more up to date PDF viewer. But I am dealing with 100s of attachments and keeping a network archive of files defeats the long term document storage purpose as it is less secure.
This is a bug, but perhaps we could have a feature to have some control over the viewer. Many Mirth Users report not trusting the viewer due to its history of not working properly just like this.
The text was updated successfully, but these errors were encountered:
As far as workarounds are concerned, the client has an option to download the attachment to the local machine, where it can then be opened by whichever pdf viewer you have installed on your local system.
Describe the bug
I have a process that pulls an embedded pdf from OBX.5 and stores it as an attachment. We have tested and used this process for years so we know that it is functioning properly.
Sometimes we do have an error whether it is network, data, or corruption. We then turn to a number of tools to assist us. One of those tools is the pdf viewer so we can see the PDF. Rarely the attachment viewer fails due to xref expected at start of table. I would say it works fine at least 85% of the time.
The error message in question makes little sense. But the xref is only required as of pdf reference up to version 3 which published in 2001. The next revision made it optional. So, the attachment view is trying to render a pdf using a 23 year old reference. I fully suspect my PDF is perfectly fine, but I cannot view it. We are not using a long term network archive where I can just drop a file with a filewriter. Instead this HL7 message is sending the pdf to our long term document storage solution.
This happens on dozens of documents.
To Reproduce
Attempt to view a PDF document stored as an attachment, certain perfectly fine pdfs will error.
Expected behavior
Actual behavior
I get an error about xref expected at the start of the table.
Environment (please complete the following information):
Workaround(s)
One can supposedly use network location to write a the attachment to a file and then use a different and more up to date PDF viewer. But I am dealing with 100s of attachments and keeping a network archive of files defeats the long term document storage purpose as it is less secure.
This is a bug, but perhaps we could have a feature to have some control over the viewer. Many Mirth Users report not trusting the viewer due to its history of not working properly just like this.
The text was updated successfully, but these errors were encountered: