I'm curious to know why you built this when the Mozilla PDF viewer exists:
https://github.com/mozilla/pdf.js
Not criticizing because there's lots of reason to build things that exist, just curious.
For app integration, the annotations, shapes, and comments are a game changer. Once you need real PDF markup tools, your options are either building them yourself or using a subscription-based PDF editor - neither comes cheap.
I know teams that integrated Apryse, and the costs just to support basic PDF editing are eye-watering.
The main goal was to make a PDF viewer that is easy for developers to integrate into their websites with minimal setup, while PDF.js can be harder to customize and extend for certain use cases
Cursory looks tells me that there are some different features, like annotation comments.
Very nice! I once had a side project with a built-in PDF viewer. My first version used pdf.js, but when zooming in quickly, it felt sluggish and hard to keep the zoom focus in the right place.
So I built my own PDF viewer, this time using pdfium in C++ with Metal for rendering — here’s a quick demo: https://youtu.be/jJMhVn5yzEI
I implemented a tiling technique to balance memory usage and performance. I didn’t realize pdfium could be so performant in WebAssembly — and honestly, I actually prefer developing UI on the web compared to C++.
Honestly, yours looks even snappier than what I had, the way it’s handling zoom feels super fluid. Really impressive work! Makes me want to dig back in and see if I can match that speed.
Thank you! Smooth zooming was the main thing I focused on optimizing. I haven’t implemented text search yet, that’s a whole other rabbit hole, with challenges like stitching text objects together and handling text normalization.
My code runs natively, so users need to download a client and I have to code the rest of the ui in cpp, that’s the downside. I did consider a hybrid approach with Electron or Tauri, but dropped the idea to avoid IPC overhead and get the best possible performance.
Gave it a quick try. Annotations didn't work at all in Fierfox, but all annotation types (underline, highlight, etc.) worked as expected in Chrome.
I haven’t had the chance to test annotations in Firefox yet, so thanks for pointing that out. I’ll check what’s going on there, good to know they’re working fine in Chrome.
Sounds like a mobile-vs-desktop issue, since the error mentions TouchEvent. The Firefox error fires even when just hovering the cursor over the PDF in View mode, and text is also not selectable.
While I'm here, a suggestion to add Undo/Redo; yes HN, I know I could make a PR..
If you haven't checked yet, you'll notice:
Uncaught ReferenceError: TouchEvent is not defined
Looks great! Diving into the docs I especially liked the idea of a headless React library so I can design my own UI and add some extra components. How difficult would it be to automatically highlight or underline certain terms in the PDF and then render a custom component when I click or hover over the term?
Thank you for sharing and being so generous with the licensing. I know this might be way out of scope, but do you have any plans for a "flipbook" visualization?
Not on the roadmap yet, but I’d definitely be open to adding it if more people are interested.
MIT license is generous. Good for you, and thanks!
Thanks! I wanted to make it as easy as possible for people to use, tweak, and build on top of it, so MIT felt like the right choice.
The underlying PDFium is Apache 2.0 though, and it looks to me that the present project doesn’t currently comply with https://www.apache.org/licenses/LICENSE-2.0#redistribution for that dependency.
Good point, you’re right that PDFium is Apache 2.0. I’ve updated the project to comply with the redistribution requirements in this PR: https://github.com/embedpdf/embed-pdf-viewer/pull/80/files. Thanks for flagging it!
Seems to work great!
Little note: when you switch from redaction to view with the redaction tool (red lines) active it stays active in the view mode. Impossible to scroll because it still redacts.
Refresh fixes it.
Good catch, I’ll fix that. On mobile, it’s intentional that scrolling is disabled while in redaction mode so you can make precise selections, but if you switch back to the view tab it should definitely exit redaction mode. Thanks for spotting it!
I tried a random PDF that includes an annotation, but the annotation didn't show up. I assume the annotations this supports are no real annotations?
We already support quite a few real PDF annotations: circle, square, polygon, polyline, highlight, underline, squiggly, strikeout,free text, stamps, and ink. Some types are still on our list, like links, form fields, sound annotations, file attachments, and 3D models. Do you happen to know what annotation type it is in your PDF? I’m curious.
Very nice! Thanks for sharing. How long are you working on that ?
Thanks! I’ve been working on it for about 7 months now.
The mobile site works well. Quite fast and snappy
The repo appears to contain a copy of Foxit’s/Google’s pdfium along with a UI and lots of abstraction layers/examples for various JavaScript frameworks.
I’m not a JavaScript developer (perhaps there are cultural differences at play?), but in general I think it would be polite to credit the developers of the actual PDF engine.
The repo is marked with the pdfjs and pdfium topics so there is that.
Beyond that, powered by... and similar make sense if the library/engine allows or encourages the behavior.
Absolutely, and I agree, credit is important. I have a whole section in the docs about PDFium and its origins with Foxit/Google: https://www.embedpdf.com/docs/pdfium/introduction.
That’s neat.
I would also mention it in the README.md.
the best solution is simply to not use PDF.
Nitpick, but Viewer is free and always has been. You're building a free alternative to Acrobat.