hckrnws

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

I think it's what many (also commercial) PDF viewers are based on.

If you want traction, I suggest you package a .dmg file for Mac users.

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.

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

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?

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.

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

Cursory looks tells me that there are some different features, like annotation comments.

Go to your link on an iPad or iPhone and open their demo document. The tap Print Preview - it only appears to work on desktop devices.

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

402 open issues, mother of God, it's a glimpse of the massive effort that is handling PDFs and all it's features.

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.

In any case, there are more native speakers of right-to-left languages then there are native English speakers.

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

I don't think there's an indication that this affects all RTL languages, just Hebrew word order in selections.

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.

But what it's worth, I as a user prefer native code with no Electron.

But it will be more difficult for me to support multiple platforms, do customizations on the ui etc.

For example, I don't even own a windows pc.

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)

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

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

Unfortunately, the Demo doesn't seem to work with my combination of Linux + Firefox. I cannot get any of the annotation/redaction tools to work.

It seems to work with Chromium on the same machine.

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.

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

Seems to work pretty well on Firefox for Android. Very impressive work!

This is really great. The speed is great, and I've had issues with Mozilla PDF viewer recently. (Printing fails for some unknown reason.)

But I assumed it was also a standalone app? Could this be used as a standalone app in some fashion?

Thanks! For now we’re only building a web app, but depending on demand we’d love to build native apps for Android, iOS, and desktop OSs as well.

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.

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!

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.

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.

Is selecting text in the PDF supported? I can’t get that to work in iOS Safari.

Text selection broken on Mac OS Safari as well. Worked in Chrome on Mac OS.

This is amazing. Unlike Acrobat Reader, this actually made me want to read a pdf. And the UI looks super professional.

That means a lot to me, thank you!

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.

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.

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

Great project.

Would be wonderful to have PKCS#11 and PKCS#12.

Thanks! Signing is a high priority for us, and PKCS#11 and PKCS#12 support are definitely on our radar.

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!

Very nice! Thanks for sharing. How long are you working on that ?

Thanks! I’ve been working on it for about 7 months now.

Requiring a whatng cartel web engine? Then, nothing to be proud of, mate.

But that's a bravery to deal with the brain damaged PDF file format.

Haha fair, but PDFium's under Apache 2.0, so at least the “cartel” in this case is about as open-license as it gets.

Huh?

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

The mobile site works well. Quite fast and snappy

Thanks! Glad to hear it’s running smoothly on mobile, the rendering on iOS in particular feels really fast.

MIT license is generous. Good for you, and thanks!

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!

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.

Nitpick, but Viewer is free and always has been. You're building a free alternative to Acrobat.

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.

[dead]

[dead]

[flagged]

Akshully to be a swastika it would have to have four-way rotational symmetry, which this kinda looks like but isn't. The Sun logo is a swastika: https://dogemicrosystems.ca/pub/Sun/media/logos/Sun-Microsys...

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

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.

That is not even close to what I thought when I saw the logo.

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.

Rent free lol

the best solution is simply to not use PDF.

I’d much rather recommend <https://pdfreaders.org/>, so people can choose depending on their situation. Does this project belong there, too?

What are you recommending? That's a list of other open PDF readers, which mostly serve purposes very different from what the author here has done.