search

shivaprsd / doqment

Mozilla's HTML5 PDF Viewer with Reader-mode add-on. 📖
https://shivaprsd.github.io/doqment/src/pdfjs/web/viewer.html
MIT License
49 stars 1 forks source link

Lagging in viewer version compared to PDF.js upstream #9

Open MagicalDrizzle opened 1 year ago

MagicalDrizzle commented 1 year ago

Would you be able to create new releases (like 0.5.x) every few weeks to months simply to catch up with upstream pdf.js? (they are at 3.11 now)
Of course I can do it myself and load the (unsigned) extension up but having it be signed would be better I think

Also on that note

Cannot use the integrated Findbar to search for text in PDF.

is false I think? at least when I open a local file with your extension I can search texts fine

shivaprsd commented 1 year ago

Hi @MagicalDrizzle, thanks for bringing this up, it is something I wish myself to do.. I know that the PDF.js release cycle is monthly, and most other extensions that use it often has very outdated versions. One of the main goal I had set for doqment was to be not far behind the upstream.

The problem is, more often than not, a release of PDF.js breaks some modifications that doqment make. So I have to manually check that the current modifications work with each new version or make changes as needed (I am not well-versed with automated tests, it is something I obviously need to look in to). This is often time consuming to do every month. 😅

Thus the strategy so far has been to do a release for every 3-4 upstream releases, which means an update every 3-4 months. If you look at the project history you will see I went from PDF.js 2.13 => 2.16 => 3.2 => 3.6 with each update. This also gives me time to add and test other features to doqment. Even by that standard we are currently due, I should have caught up with 3.10 at least. Currently I am out of town, I will work on it as soon as I get back. 😬

Another thing I could do is make a 0.5.x with each upstream release as you said, and then fix if anything is broken in 0.6. But this means my users might have to put up with a broken viewer for months till I am finally able to resolve the issues (as most people have auto-update turned on for extensions). They might actually stop using doqment if so.

What we really need is something like a beta-channel for users who want to be up to date with upstream even if some doqment functionality is broken. They can also find and report the broken stuff quicker, which means faster releases on the stable channel too! I will have to check how the extension store handle beta's. The last time I had checked, there was no beta channel option.

Finally, PR's are welcome! If you could drop a new upstream release and test everything is working, please open a PR and we could have a new release faster. BTW I suggest we use 3.10 for now, to match the pattern so far.

shivaprsd commented 1 year ago

Regarding the integrated findbar, what I meant is the findbar built in to Firefox. The generic viewer we use has its own findbar to search for text, which can be accessed via the 🔍 button on the toolbar.

The native PDF.js viewer of Firefox does not have that button and the associated findbar. It makes use of the standard Find feature of the browser itself. I guess these screenshots will make it clear:

Findbar doqment uses Intergrated Firefox findbar
doqment firefox

(see 🔍 button is absent in the second case)

shivaprsd commented 11 months ago

@MagicalDrizzle I have released v0.6 with PDF.js version 3.10. Just like I said, the new Stamp annotation editor broke in doq and I had to fix. 😄

The upstream has now gotten in to v4 which I hope to cover by the next release. To compensate on the lag on this one, you can expect v0.7 sooner. 🌝

And from then on we can find a way to catch up with monthly upstream releases.

MagicalDrizzle commented 11 months ago

thank you! my apologies if I sounded demanding, I promise I just saw how your version were lagged behind and decided to ask... I hope you do your best ^^

shivaprsd commented 11 months ago

Not at all! As I said, avoiding the lag was one of my main goals, you only reminded me of it. And so I also keep this issue open. :slightly_smiling_face:

MagicalDrizzle commented 11 months ago

Two questions:

  1. Do you think it would be a good idea to toggle pdfjs.disabled on to disable the builtin viewer?
  2. Do you think it would be a good idea to show the original pdf link even when the document is rendered in a frame? (sci-hub etc) Currently if you follow the actual link, e.g https://zero.sci-hub.st/1554/5e641c653846c93a84442cac49a6513f/hong1994.pdf the popup does show up, but if you simply use the DOI https://sci-hub.st/10.1006/jmbi.1994.1638 (so sci-hub renders the pdf in a frame) it doesn't.
shivaprsd commented 11 months ago
  1. Yes, absolutely. That would in fact be the recommended way for experienced users. But disabling it via the settings has more or less the same effect, I guess.
  2. I don't think so. What if a page has multiple PDF frames? Which link should we show in the popup then?

But you can view the original link also via the Current Page option in the overflow menu (top right). It is a link in disguise; like any link you can hover over it to see the url, right click and Copy Link, etc. It also includes the page and zoom info in the link though (after a #), but these can be easily removed.

The popup exists to make it easier to view/copy the original link from the address bar, where it is buried inside the unsharable moz-extension://xxxx... url. In the given example, the DOI url is still a clean, sharable url.