PSPDFKit's company blog covers its PDF SDKs, with posts on WebAssembly, iOS, cross-platform development and performance.
HN links it for WebAssembly benchmarks and PDF tooling. Commenters note the company's SDK and job listings, and its CTO discusses WebAssembly's limits.
ignoring the "thoughts on flash"[0] letter, the apple <=> adobe relationship goes back to at least the apple LaserWriter[1], so that would definitely make sense
the Quartz compositor itself has "use[d] pdf internally"[2][3] ever since the initial launch of Mac OS X
> By the time OS X came out, these were less the kind of features that "the next great personal computer operating system" should have, and more the kind that they all had. What was new included how Quartz, the engine for OS X's "killer graphics," was based on PDF.
> "What does that mean?" asked Jobs. "You know when you go to the web and you see PDF documents? Well, that technology is now at the core of Mac OS X's graphics. So you can image PDFs instantly. So now all applications get this for free."
> It's how, to this day, every Mac app can produce a PDF document without needing a third-party app.[4]
[0]: https://web.archive.org/web/20100531072734/http://www.apple.com/hotnews/thoughts-on-flash/
[1]: https://en.wikipedia.org/wiki/LaserWriter#Apple's_development
[2]: https://www.youtube.com/watch?v=Ko4V3G4NqII / https://www.youtube.com/watch?v=6-fkYFV7rOY
[3]: https://en.wikipedia.org/wiki/Quartz_(graphics_layer)#Use_of_PDF
[4]: https://appleinsider.com/articles/21/03/24/apple-launched-its-revolutionary-os-x-20-years-ago
https://pspdfkit.com/blog/2020/apple-and-pdf-history/
PSPDFKit CTO here.
I 100% agree with you that our current implementation misses out on lots of browser-provided native behaviour. But this is not an inherent limitation of WebAssembly.
PSPDFKit started as an iOS-only framework. We then abstracted out a shared C++ layer which has tight hooks with the platform (Android or iOS).
PSPDFKit for Web is still a young product, one feature we have on our long-term roadmap is to have the browser handle rendering text natively. Our WebAssembly Core can "extract" WebFonts for the glyphs from the PDF and position them using HTML tags. This truly gives you the best of both worlds. PDF files need to be rendered absolutely accurately, so for now we went with rendering to an image.
If you're interested in our cross-platform strategy, you might be interested in https://pspdfkit.com/blog/2016/a-pragmatic-approach-to-cross-platform/
PSPDFKit | REMOTE | Full-time | Elixir
We’re looking to hire a backend developer to join our team working on PSPDFKit for Web (https://pspdfkit.com/pdf-sdk/web/).
We are building a modern PDF SDK with technologies like Elixir, React, PostgreSQL, Docker, and WebAssembly. Your role as a backend engineer will be to implement new features, improve the reliance of our server component, and work on scalability problems in a well-tested Elixir application.
If you're interested in working for a fully bootstrapped company, with a team all over the globe, that iterates quickly and uses a modern, pragmatic tech stack, then check out our job ad: https://pspdfkit.com/careers/backend-developer/
Taking a quick look at https://pspdfkit.com/api/documentation/tools-and-api/, I'm puzzled.... what distinguishes a "PDF Generator" from a "PDF Creator" from a "PDF Writer"? How would I know which one I want?
Oh, looks like they're the exact same thing: a webpage-to-PDF service.
Then there are a whole bunch of "PDF Converter" options, including "HTML > PDF", which seems to be yet another name for the same thing.
For me, all this has a whiff of SEO spam that I find quite distasteful. Just tell me what the product does. Don't try to list it under a collection of different titles in the hope of catching more search terms, it just makes you sound like a snake-oil salesman.
Also had much success with it in the past. In my previous job we wanted to use it when building Xcode projects with a large C++ library. However, it's not compatible with Apple's modified Clang. I spent some time maintaining a fork where I hacked in support for passing along the Apple specific switches but eventually gave up. Seems like a cool feature would be the ability to define non-standard switches in a config rather than have them hard coded.
edit: just remembered I wrote up a blog post about it when I worked there
https://pspdfkit.com/blog/2017/crazy-fast-builds-using-distcc/
PSPDFKit (https://pspdfkit.com) | Frontent Web Engineer; iOS Engineer; Support Engineer
PSPDFKit is a remote company building SDKs for document display (PDF + Images). We are on all platforms (even Windows) and used by basically all cloud storage providers.
Modern React-based tech stack on the Web SDK. Also lots of C++.
Interesting challenges since we not only want to design a great product, but also an easy-to-understand API with many customization points.
Bootstrapped company here. We make money by selling products. No VC BS.
https://pspdfkit.com/jobs