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.

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

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.

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

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.

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

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

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

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.

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.

Huh?

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

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

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!

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!

That’s neat.

I would also mention it in the README.md.

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.