Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Failure of the PDF attachment viewer #6138

Open
michaeljeffreycollins opened this issue Mar 20, 2024 · 1 comment
Open

[BUG] Failure of the PDF attachment viewer #6138

michaeljeffreycollins opened this issue Mar 20, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@michaeljeffreycollins
Copy link

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.

@michaeljeffreycollins michaeljeffreycollins added the bug Something isn't working label Mar 20, 2024
@tonygermano
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants