Note that actual hard work here seems is done by PDFium, which is what Google bought from Foxit and then relicenced (and keep developing themselves), and which is now in Chrome.
(I don't take from your work btw, just that it's not a new PDF parser written from scratch or anything.)
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
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.
This may be hairsplitting, but emphasis on the handling word in that sentence. I would bet it's not so much the feature gap it's that the specification is very, very YOLO. And when any number of byte sequences happened to render as a PDF[1], then such a situation leads to a very, very diverse set of inputs that coincidentally work on some systems leading to "works on my machine" type outcomes. When your project is in the business of rendering things which happen to work in ${other system} it leads to a lot of very angry users
1: it's like the million monkeys with a million typewriters decided to go work at Adobe and they really have heard great things about mixed text and binary file formats because they are outstanding RCE and stack smashing opportunities
On the one hand, a lot of those are feature requests, not necessarily bugs. They also have more users, so they catch more edge case bugs like "Hebrew is rendered backwards" and so on.
On the other hand, PDF.js has been around for more than a decade. As it is a core component of Firefox, and viewing PDFs is an important part of name business applications, you'd think they'd have not nearly so many issues.
I know PostScript and PDFs are a nightmare, but no small part of me feels like this is yet another case of Mozilla underfunding development.
When you're not a Hebrew speaker and you don't interact with Hebrew script, and you're developing a PDF library by yourself, it's easy to not even realize that there is something about it that you've overlooked.
I don’t see dotancohene say anything about how surprising it is that that bug exists. They only say something about the judgment of it being an edge case.
I found this and dropped their table into a sheet to get a a total of just over 2.3 billion.
Languages using right-to-left scripts https://share.google/lN5lmfjCoIW7ENvdZ
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.
From what I understand there are two good FOSS PDF applications for Windows. The platform that is in need of a good PDF application, where you'll acquire users, isn't Windows.
We use pdf.js, a bunch of problems I encountered when testing and comparing (17 MB, 158 pages, many images, Windows):
* Links don’t work
* Bookmarks show up but don’t work either
* Text selection doesn’t work in FF
* Middle-clicking (to scroll) in Chrome triggers text selection
* Very slow rendering, when I scroll in pdf.js, everything looks fine. When I scroll in this, everything looks low quality and blurry for ~500-1000ms. Worse for jumping multiple pages at once, e.g. using "end", I get a white page instead of a low quality page.
* Up/Down, Page Up/Down, Home/End don’t work in FF (left/right does work)
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..
Thanks for letting me know, that was related to a Firefox-specific issue I’ve just fixed. Annotations and redaction should now work in Linux + Firefox as well as Chromium.
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?
Very easy, this already works! In the AnnotationLayer you can add your own `selectionMenu` and render any custom component there. If you want to dive deeper, join our Discord and shoot me a message. https://discord.gg/mHHABmmuVU
This looks really impressive! I'm curious about the monetization strategy - how do you plan to sustain development of such a feature-rich PDF viewer while keeping it free? Are you considering enterprise features, hosting services, or other revenue streams?
Yes, all of the above. The client-side PDF viewer will remain free and MIT-licensed, but I’ll be focusing on offering PDF hosting with enterprise features like analytics, access controls etc, those will be part of the paid offering.
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.
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!
It would just take one additional component in your NPM package which contains all the more "internal" stuff. Just put the advanced example you have now in one component.
The example with the engine etcetera looks more like an advanced example.
It gets a developer to a quick result in their own app. If they want to go further they can nothing changes there.
A sidenote: That same though might be something with your NPM import - just one would be a better dev experience to start while I understand why you offer them separately for more advanced.
This is really valuable feedback, thank you! I agree, having a simple, ready-to-use `<EmbedPDF>` component that includes all the plugins by default would make it much easier to get started. I’ll definitely add that alongside the more advanced example.
KOReader user here, very happy to try something new. I use annotations very heavily, on a KDE based Debian system, on a Samsung Ultra device with the S-Pen, and with a large E-ink tablet with an EMR stylus. I use many mixed LTR and RTL text. I work with code and with documentation and with scientific articles.
If you want a demanding user with diverse use cases to test on diverse devices, you are invited to contact me. My Gmail username is the same as my HN username.
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?
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.
In my experience links and form fields are the two above you encounter most often in the real world. The problem with forms though is that you potentially open up scripting, for better or worse. I mean you're already in Javascript, so you could handle it a lot easier than Preview on MacOS could, but it is of course worrisome that you'll be running code from an arbitrary PDF…
I wish I was still working at Apple and had my suite of nasty PDF's to test with. Some were just huge files (like a catalog for McMaster-Carr or wherever), another (a version of The Bible?) had an odd text layout across the columns on each page (for testing text selection), maybe one file was a huge single-page PDF street-map of a city (with lots and lots of rendering code and arbitrary text runs all across the map, etc.).
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.
It doesn't matter if it is exact or not. It is a problem that people may think it looks line a swastika.
Certain places in Europe, for example Austria and Germany, are far more sensitive in those regards, for obvious historical reasons. You really don't want to be associated even remotely with those kinds of things. Even if the similarity isn't sufficient to land you in jail, it will lead to weird looks, social ostracism, loss of business and jobs, hostile behaviour, and increased attention by the authorities.
If you never want to do business or live in central Europe, fine, ignore all that. I know that the rest of the world is more relaxed. But just as USian sensitivities sometimes induce a heated discussion about why a visible nipple isn't actually harmful, this is one of those topics from the European perspective.
I did not see it either until it was pointed out. I probably would not make the connection again if I saw the logo after a reasonable gap of time. Projects are brought down or are less than they could be other wise because logo choice or name choice though so this case is hard for me to immediately brush it off without doing research/survey/etc, (edit) mostly because I am not familiar with the area.
(I don't take from your work btw, just that it's not a new PDF parser written from scratch or anything.)
https://github.com/mozilla/pdf.js
Not criticizing because there's lots of reason to build things that exist, just curious.
- Is it written from scratch? - Did you have prior experience with PDF format and rendering?
Stupid question: Do you feel LLMs can do that kind of work beyond typical SPAs with forms and CRUD?
I know teams that integrated Apryse, and the costs just to support basic PDF editing are eye-watering.
1: it's like the million monkeys with a million typewriters decided to go work at Adobe and they really have heard great things about mixed text and binary file formats because they are outstanding RCE and stack smashing opportunities
On the other hand, PDF.js has been around for more than a decade. As it is a core component of Firefox, and viewing PDFs is an important part of name business applications, you'd think they'd have not nearly so many issues.
I know PostScript and PDFs are a nightmare, but no small part of me feels like this is yet another case of Mozilla underfunding development.
In any case, there are more native speakers of right-to-left languages then there are native English speakers.
In any case, Hebrew is handled differently from other RTL languages, hence this bug report in PDF.js: https://github.com/mozilla/pdf.js/issues/20097
Almost certainly something a smaller team would have never caught, given that a team with a massive name behind them didn't.
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++.
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.
For example, I don't even own a windows pc.
From what I understand there are two good FOSS PDF applications for Windows. The platform that is in need of a good PDF application, where you'll acquire users, isn't Windows.
* Links don’t work
* Bookmarks show up but don’t work either
* Text selection doesn’t work in FF
* Middle-clicking (to scroll) in Chrome triggers text selection
* Very slow rendering, when I scroll in pdf.js, everything looks fine. When I scroll in this, everything looks low quality and blurry for ~500-1000ms. Worse for jumping multiple pages at once, e.g. using "end", I get a white page instead of a low quality page.
* Up/Down, Page Up/Down, Home/End don’t work in FF (left/right does work)
While I'm here, a suggestion to add Undo/Redo; yes HN, I know I could make a PR..
It seems to work with Chromium on the same machine.
Probably the number one missing feature of PDF editors/viewers. Miss it everytime someone sends me a PDF without outline.
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.
https://www.embedpdf.com/docs/react/getting-started
I would suggest that you start with a more simple example. like:
<EmbedPDF url={https://snippet.embedpdf.com/ebook.pdf}/>
It would just take one additional component in your NPM package which contains all the more "internal" stuff. Just put the advanced example you have now in one component.
The example with the engine etcetera looks more like an advanced example.
It gets a developer to a quick result in their own app. If they want to go further they can nothing changes there.
A sidenote: That same though might be something with your NPM import - just one would be a better dev experience to start while I understand why you offer them separately for more advanced.
But I assumed it was also a standalone app? Could this be used as a standalone app in some fashion?
If you want a demanding user with diverse use cases to test on diverse devices, you are invited to contact me. My Gmail username is the same as my HN username.
I wish I was still working at Apple and had my suite of nasty PDF's to test with. Some were just huge files (like a catalog for McMaster-Carr or wherever), another (a version of The Bible?) had an odd text layout across the columns on each page (for testing text selection), maybe one file was a huge single-page PDF street-map of a city (with lots and lots of rendering code and arbitrary text runs all across the map, etc.).
Would be wonderful to have PKCS#11 and PKCS#12.
But that's a bravery to deal with the brain damaged PDF file format.
This is not related to the LICENSE, it is related to the technical dependency on a whatng cartel web engine (geeko/blink/webkit).
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.
Beyond that, powered by... and similar make sense if the library/engine allows or encourages the behavior.
I would also mention it in the README.md.
I am also fine with calling things swastikas in a non-judgemental purely-heraldic way. Being a swastika doesn't mean something should be compared unfavorably to that swastika lol <https://commons.wikimedia.org/wiki/Category:Swastikas_in_her...>
Certain places in Europe, for example Austria and Germany, are far more sensitive in those regards, for obvious historical reasons. You really don't want to be associated even remotely with those kinds of things. Even if the similarity isn't sufficient to land you in jail, it will lead to weird looks, social ostracism, loss of business and jobs, hostile behaviour, and increased attention by the authorities.
If you never want to do business or live in central Europe, fine, ignore all that. I know that the rest of the world is more relaxed. But just as USian sensitivities sometimes induce a heated discussion about why a visible nipple isn't actually harmful, this is one of those topics from the European perspective.
It needs a web browser so no alternative to Adobe PDF viewer.