Open Discussion: Remove PDFjs

[hawkeye64]

I am considering to remove the PDFjs dependency and go back to just the HTML5 PDF Viewer (as it was originally). The latter is more light-weight, because it uses the internal PDF Viewer built into the browser. However, this excludes Electron/Capacitor/Cordova, etc. In which case, these platforms should use the PDFjs on their own, or an extension could be written to incorporate it.

Ever since the PDFjs dependency was added, this project has stalled out because of the issues with PDFjs.

Please voice your concerns and/or advice here.

[mesqueeb]

Maybe you can just split the library in qpdfviewer and qpdfviewer-universal where universal is the one that is capable with capacitor.

Or maybe you can split the library in qpdfviewer and qpdfviewer-light where light is the one that only has HTML5 support.

For me personally: Any place I need to show PDFs I need a solution for Capacitor as well at the same time.

[mesqueeb]

I just have a new project that will only be used in browsers, so I won't need the PDFjs dependency for that.
For some other Capacitor apps, I switched the logic to it opens PDFs inside an in-app-browser and therefor just uses the iOS browser PDF viewer. It works just as well really and it made it possible for me to remove the QPdfviewer dependency, making the app much lighter.

So I'd say: fork this repo and do one of these:

• qpdfviewer______ and qpdfviewer-universal
• qpdfviewer-light and qpdfviewer
• qpdfviewer-light and qpdfviewer-universal

[hawkeye64]

@mesqueeb Good point - I like the idea of QPdfviewerLight

[hawkeye64]

I am still on the wall for this and haven't done anything because of lack of suggestions/ideas/etc :(

[cabassi]

Hi @hawkeye64, I'm gonna report what happened when we tried to use this extension in one of our apps.

So basically we were developing an app (quasar & capacitor) for the hunters in Switzerland and we needed to show a pdf that was several pages long (>100) and it needed to work offline and refresh its contents when there was connectivity.

We ended up opening the file as an external file because this and other pdf viewers we tried were not working well on mobile because of pdfjs and it's sluggishness or because of the bad UI/UX they had.

I thinks that most use cases on capacitor, or mobile in general, are these:

1. view the pdf
2. be able to search for text in the pdf
3. see the page you are at

The top bar that is currently displayed is not very attracting on mobile 'cause it's stealing some screen real estate, which on mobile isn't many.

On mobile most of the time you just need a "pdf scroller". I'd also suggest to fork the extension and have something like this:

• qpdfviewer -> mostly to be used in desktop apps (HTML5 only)
• qpdfviewer-universal -> same as qpdfviewer, same interface, only with the support of pdfjs as a fallback when the native HTML5 viewer is not available
• qpdfviewer-mobile -> an app ext with a much simpler UI, built with pdfjs and optimized for that, and wrote with a mobile UX in mind.

I've got also some ideas on a possible UI for the qpdfviewer-mobile, let me know if you're interested in seeing a sketch!

[hawkeye64]

@cabassi Yes, please! I have recently been inspired by @jesusvilla in some recent work he has done. Hoping he will help out a bit here. Yes, I do like the multiple app-extensions. I feel pdfjs is a burden, if you just need to access the HTML 5 Pdf Viewer.

[jesusvilla]

Thank's for the interesting ideas.
To make the pdf viewer, it is necessary to have pdf.js but not its viewer, if not the core and thus achieve full control of the UI, that is why we are working on it, so everything lives within the Quasar ecosystem ( created and optimized on Quasar components) in turn taking into account the user experience on mobile devices which implies some mobile gestures, among other things, so I ask you a little more time, I have been inspired by the main libraries of the market: PDFTron and PSDPFKit.

[cabassi]

I agree with you @jesusvilla, the mobile ext needs to take into account for mobile UX!
And in my opinion you don't need to be able to edit the pdf, highlight text ect..

I mean, you can maybe on a tablet, but for smartphone I think less than 1% of the apps that shows a pdf need to edit it.
Of course, if editing capabilities are needed one could always use qpdfviewer-universal and go home with it.

I made a very basic XD

Some additional considerations:

1. The overlay (called info overlay) that shows the page you're at and the search button appears only when you are scrolling and disappears automatically after you stay still for more than 3 seconds. This way you can read the pdf without distraction and enjoying the full content. In XD this is not well represented because of the XD's own limitations.
2. When you scroll down the page number is updated accordingly to your viewport and the info overlay stays fixed on top of the page. In the XD when you scroll down and the top-bar go away it should got on top where the top-bar was.
3. There's no need for a page selector since scrolling is so fast that for less than 300 pages it faster to scroll rather than opening the page selector, typing the page number and tap Go.

This behavior is very similar to how Apple Safari works when showing PDFs.

@jesusvilla a note: what are you saying about PDFtron and PSDPFkit is valuable and these are good ideas for the desktop version of this extension, but for mobile, I think it's not worth it.

What do you think ?

[hawkeye64]

@cabassi I like where you are going with the design. I am curious what would be in the hamburger menu...

[cabassi]

The hamburger menu is just for navigation. I extracted this from a mockup of the JagdGR app

What I wanted to show was just the super minimalist overlay which is shown when you scroll the pdf.
I find qpdfviewer-mobile should be that simple.

Do you think that's something you may be interested to develop ? What are your thoughts on mobile pdf fruition ?

[jesusvilla]

Desktop version

Mobile version

[jesusvilla]

I think there should be a property with 3 modes: desktop, mobile, auto. By default it will be in auto determined by vm.$q.screen.lt.sm so that it is indicated in mobile mode.
The main difference will be the toolbar, with it comes mobile support and its gestures, I hope to get to pinchzoom.

I'm still developing it, so ask for a little patience please as i'm taking into account UI and performance. I hope it is to the liking of the whole community. ❤️

[cabassi]

@jesusvilla That's a fantastic news! I'm sure the community as a whole is going to appreciate your hard work.

As for mobile, what plans do you have about navigation between pages and in the page itself?
Do you think you'll be able to implement scroll up and down to navigate between pages? (With continuous scrolling instead of viewing 1 page at a time?)

[jesusvilla]

Thank you @cabassi, by mobile do you mean this?

[cabassi]

Thank you @cabassi, by mobile do you mean this?

Yes! Sorry I didn't imply that was a thing since a saw the two arrows for navigation. In fact I wonder what are these for if you can scroll with your thumb ;)

Btw it seems pretty neat already!

[jesusvilla]

the navigation buttons have the other viewers, so I put them, it's never too much. 😉

[cabassi]

Personally, for mobile I think they're not needed.

I found giving a user too much ways to do a thing to be counterproductive. Of course it's not the case for a thing that simple like a scroll / tap a button, but it's a principle I like to follow from the most basic UI interaction.

Maybe you can have a prop to hide / show the arrow buttons, so if someone feels it's not needed they can just hide them.

I'm looking forward to see this ext :)

[jesusvilla]

I agree with you, overloading with options is bad, but this is not the case, sometimes it is easier to scroll directly on each page (navigation button) or other users may believe that it's more comfortable with using the scroll. Also, the idea is that each button can be shown or hidden.

[cabassi]

You thought every detail. Thanks for your work!

Feel free to ask for feedback or help with testing. I'm glad to help if needed.

[jesusvilla]

@cabassi thanks for your ideas, you are already contributing a lot 👍

[gmalignon]

I would like to add my own experience. I use QPdfviewer in a Quasar Android Cordova project and the only way I could get it to work is by using the pdfjs type. Actually unlike what the documentation states, the pdfjs type works fine with blobs. I have a core .net back end which sends a base64 string and the plugin displays PDFs fine with a blob.
I couldn't get it to work at all using the html5 type, so I think 2 versions are needed.

[hawkeye64]

@gmalignon The html5 uses the internal PDF viewer built into browsers. Electron and mobiles do not have this capability. That's why PDFjs was origainally added. However, PDFjs has more flexibility that can be programatically accessed.It's likely we will now keep PDFjs and ditch the html5 version.

[hawkeye64]

The latest was just released with Quasar v2/Vue v3 support.
https://github.com/quasarframework/app-extension-qpdfviewer/releases/tag/v2.0.0-alpha.1
Closing this issue. If you feel the need create a new issue. Thanks.