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.

Not sure if it matches your vision but I just took a look at the react example:

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.

That’s neat.

I would also mention it in the README.md.

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.).

If you haven't checked yet, you'll notice:

    Uncaught ReferenceError: TouchEvent is not defined

https://developer.mozilla.org/en-US/docs/Web/API/TouchEvent#...

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..

Redaction doesn't seem to work in Firefox either. Otherwise looks great!

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!

Out of curiosity:

- 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?

Yes, those commercial PDF SDKs charge crazy prices! Time to change that.

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.

  > they catch more edge case bugs like "Hebrew is rendered backwards" and so on.

Why would you blame Mozilla for that instead of Safari? Works just fine on Android using both Chrome and Firefox.

Very cool. Having something to fill forms and sign them that works and isn't Acroread would be even more awesome than you project already is!

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.

Huh?

This is not related to the LICENSE, it is related to the technical dependency on a whatng cartel web engine (geeko/blink/webkit).

By ”recommend”, I meant, “nice link to send to people who want a suitable PDF reader”. As the headline puts it, “a free alternative to Adobe Acrobat PDF viewer”.

Would be awesome! The only free PDF editor that works on linux to support that currently is PDF4QT. If you accept PRs I'd be happy to contribute too.