Replace PDF preview with actual PDF
Context
There's some issues with the current preview mechanism:
- The preview is an html approximation of what your pdf will look like. You might end up with differences between what you see in the preview and what you see in the downloaded pdf file.
- Once the preview iframe has loaded, there's a second where you see a blank page before you see the content. That has a "flashing" effect and is not great UX-wise. There's no way to capture the event that the content is showing, since it's only happening in the iframe.
- Zooming in and out needs to regenerate the preview from scratch. This is (and looks) slow. It might also be a resource hog for the microservice.
- A preview is generated html that is stored in a temp folder and then served from that folder. This creates issues when scaling the microservice, as the folder might be created in server A, but the request might go to server B, which doesn't have that folder.
Proposal
Always generate and serve an actual pdf that gets displayed in the same box as the current preview mechanism.
This would address the four points above:
- You get the real pdf, so there cannot be any differences between preview and download.
- There will be no flashing. We can smoothly show a loader while getting a file, then display the pdf once we have it.
- Zooming in and out will create no calls to the microservice whatsoever.
- We'll be simply serving a static file, so each microservice instance in a scaled environment will be stateless.
Implementation considerations
[coko client]
- We would need a pdf viewer component (perhaps extending Mozilla's pdf.js library)
[pagedjs microservice]
- We would need to make sure we delete generated files after they've been served, or at least clean them up regularly to prevent storage space issues from building up over time.
- We might also want to introduce the option of generating pdf files with lower-res images to keep file sizes down for previews (but keep them high-res for downloads)
Alternative approaches
There could be a concern regarding the size of the pdf and any latency while the user is waiting for the pdf to be transferred. We need to run tests to see how much of an issue this actually is. It might be worth noting again that even if there is a performance hit, we will not be doing any calls when zooming in and out, so the performance changes on an individual call basis might be worth it. Latency could also be addressed by reducing the image resolution for previews (described above).
The flashing could be addressed by introducing a mechanism in pagedjs that notifies the renderer of the preview that the content has now been loaded.
The scaling issue could be addressed by using a docker volume that is mounted and shared between instances of the microservice. This works, but is not ideal for devops.
Open issues
Scaling issue: #899