This is a somewhat big update for PDF.js which is kind of cool in that they haven't really been updating it as aggressively as they usually do in the last year or so.
It's a bit frustrating to work with though. The entire concept of rendering a PDF via JS is fascinating but actually using the API has been a huge pain for us.
We've had to fork it internally and work on typescript bindings and other features to get it to work.
They seem to have a silly policy of only allow developers to use a subset of the API not the whole API itself so that it doesn't look like PDF.js (which I don't understand).
A lot of the functionality just isn't available otherwise.
PDF.js dev here. I'm a bit confused on which part of internal API you would like to use? The way I think of it, there are really three API's in pdf.js:
1) Main thread API (api.js) which we base the version off
2) The code that runs in the worker
3) The viewer components (web/*)
Quite awhile ago when we decided what parts of the API to version, we thought more people would want to use #1. Now that the project is mature we could probably expose some more base the version off of that.
As for the "so that it doesn't look like PDF.js", we don't limit the API because of this. That suggestion (which I don't totally agree with) came from what we saw people doing, where they'd copy the entire viewer, when it'd probably be better to just let the user's browser choose how to show the PDF.
I'm so sorry about being forward but why the hell don't the vim keys (hjkl) smooth scroll? Its so frustrating. Is there an option to set it as so? Using the arrow keys is so cumbersome.
PDF.js already supports h/j (and p/n) keys to page up and down. (I added them years ago. :) I think GP is asking for the keys to scroll the page by smaller steps instead of page up and down.
I've been working on an internal tool for my company using the same library. It's saved me a ton of work, but my experience has been similar to yours. I've even had to lock in to a much older version for want of putting a lot more work on my plate since the API seems to have changed a fair bit. (well, between it and JSDOM which I am using to some rendering on the server). And like you I've had to write a bunch of the bindings/definitions myself or just reduce them to nil (declare module "yadda/yadday/thing" as any)—which is thankfully permissible since it just needs to be built once and run "forever" with near-zero need for feature additions, etc.
All to extract images in a routine fashion.
Just the same, I'm still immensely thankful they've published the library as OSS.
Unfortunately, it and Poppler, and Imagemagick, etc were all off the table. I was confined to running everything within a Node instance. Couldn't make calls out to command line tools. I tried probably 20 ways of using Poppler-based libraries to no avail.
It definitely would have been the better performing route, and simpler to implement. As it is, since the app is low traffic for actual processing of the images it doesn't matter too much, thankfully.
Looks cool! On a sidenote, I've always been curious with product sites: what's your metric for including other orgs under "Used and Trusted by Top Organizations"? How do you know they use / trust it?
Do you have, by any chance, any good resources on PDF.js? The README on the github is ok, but it doesn't really cover what workers are supposed to do and provide any useful mental model for the architecture of the whole thing.
This is a somewhat big update for PDF.js which is kind of cool in that they haven't really been updating it as aggressively as they usually do in the last year or so.
It's a bit frustrating to work with though. The entire concept of rendering a PDF via JS is fascinating but actually using the API has been a huge pain for us.
We've had to fork it internally and work on typescript bindings and other features to get it to work.
They seem to have a silly policy of only allow developers to use a subset of the API not the whole API itself so that it doesn't look like PDF.js (which I don't understand).
A lot of the functionality just isn't available otherwise.