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.
Patch author here. bzbarsky's comment covered most of it. It hasn't turned out to be that difficult. On linux, it was mostly playing whack-a-mole of avoiding calls in to gtk/x11 and then creating headless implementations of the platform specific code.
One slight complication of headless has been wiring up the headless "widgets" (in Firefox, we refer to most of the platform specific code as widgets e.g. there's gtk widgets, cocoa widgets, windows widgets). Usually the widget type is defined statically at build time, but in the case of headless we wanted Firefox to either use the headless widgets or the platform specific widgets at runtime. Luckily, some of the work on multi-process Firefox work also added another type of widget and made it much easier to support multiple types of widgets.
Overall, the hardest part has been trying to replicate all the events that would normally be triggered by the platform gui code. I've also found that these events and order can vary per platform which makes it hard to do in a non-platform specific way. We're still working out some issues here.
On the Firefox side, we are considering supporting the protocol or a subset of it. It seems many people have had lots of trouble with WebDriver/Selenium in the past and are hesitant to use it. However, it is nice that WebDriver has a W3C standard which could provide a nice path forward for headless cross browser use. This would probably require browser vendors to make it a first class citizen and work out some the kinks of the spec though.
BTW, I'm in Mozilla San Francisco office, so I'd be happy to chat about the headless cross browser future if anyone from the headless Chrome team is around.
Patch author here: To add to the other comments, you could also use SlimerJS[1]. Though I don't know if I'd consider that lower level. We're open to supporting other ways of controlling FIrefox and have been gauging feedback on what to support.
For those interested, Firefox is also going to support a headless mode. The current nightly supports headless SlimerJS on Linux and more platforms will come soon.
As I mentioned elsewhere, there haven't been any full time mozilla devs on PDF.js for quite awhile. I'm not sure I actually see the whole maintenance cost savings argument since PDF.js has practically cost Mozllia nothing the last few years. A lot of bug fixes have come from unpaid contributors in that time.
Initially, PDFium was pitched as a freebie if we added support for chromium's flash and then we'd also get improved PDF printing and form support. However, the amount of effort that has gone into supporting PDFium is already far beyond what it would have taken to improve PDF.js form support and help improve Firefox's printing (which would have benefited the web in general). Though, this is my very biased opinion as I was tech lead of PDF.js.
Good god. So the project was already unmaintained, and now they're dropping it in favour of a maintenance burden, all the while regressing from a JS solution to a plugin-based native one?
I was wrong, Mozilla isn't in a free-fall. They hit the ground and are now digging the grave to bury themselves in.
Yury and I are the only paid staff that work very occasionally on PDF.js. We both have not been full time on the project for quite awhile. We do have a pretty active community and quite a few outside companies using PDF.js though.
Thanks. Your answer and your work even more so are very much appreciated! I hope you can keep it up. Maybe some of the other companies could also jump in with as financier (though I do not have too high hopes for this as taking is more common than giving...)
Seems like the Internet Archive would be the most likely org to care: a Javascript renderer for PDFs lines up with their "preservation and easy display through in-browser emulation" philosophy.
1. pdf.js has only seriously attempted to implement forms over just the last few weeks, and has made significant progress[1] not to mention someone did quite a bit of it on their own 4 years ago and no-one seemed interested in working with him. [2]
2. Mozilla has a strong interest in furthering web technologies, and pdf.js could be used in just about every enterprise LOB and government form based workflow (as they slowly move to web technologies), if it matured a bit more. Has Mozilla thought of how their unique position as a non-profit could enable them to partner in ways a corporation could not? The insurance industry on its own produces 10s if not 100s of millions of pages of PDFs every day...has anyone from Mozilla ever talked to ACORD (or even knows who they are?)
Interesting. I didn't know that someone had started working on form support (in 2016 or 2012). PDF.js started in Mozilla Research as a demonstration, and benchmark, for JS and Canvas capabilities. I don't know how much work adding full form support would be. PDF is a complicated format and I imagine there are a lot of corner cases.
(I work for Mozilla but am not involved with PDF.js or PDFium.)
Acroform support (so not the proprietary Adobe Livecycle XFA stuff) is relatively straightforward once you understand the underlying PDF specs. It's been around since PDF 1.2 (1996!!)
At the rate I see development moving, pdf.js should be able to handle, say, every IRS form well before the end of the year, perhaps much sooner.
If I had the skills or resources to help now, I would.
I still don't understand why Mozilla has apparently not reached out to the larger business/governmental universe to see if they could partner in moving pdf.js forward. A single large insurance company might spend millions each year on licensing and implementing pdf "solutions". I can only imagine what the US government uses (or could use.)
Has anyone from Mozilla spoken to 18F?
Perhaps even a open (and not proprietary) JSON (instead of XML) based form standard for "next-generation" forms could be implemented, with PDF.js at its core. (see https://github.com/modesty/pdf2json I linked to before for an element of that...the author is an employee of Intuit...perhaps it's already being used by them for their online tax software?).
