Show HN: I built a free alternative to Adobe Acrobat PDF viewer

This discussion centers around a new PDF viewer built by bobsingor, utilizing the PDFium engine compiled for WebAssembly. The key themes that emerge are the viewer's performance, its features (particularly annotations), the choice of PDF engine, licensing, and potential future developments.

Performance and User Experience

A significant portion of the conversation focuses on the perceived performance and user experience of the new viewer, especially in comparison to pdf.js. Early feedback highlights the smoothness of the zoom functionality.

• billconan contrasts their experience with pdf.js, stating, "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," leading them to build their own solution with PDFium.
• bobsingor's work is praised by bobsingor (likely a typo, intended to be bobsingor as the author of the viewer who is responding to billconan's shared video demonstration) stating, "Honestly, yours looks even snappier than what I had, the way it’s handling zoom feels super fluid. Really impressive work!"
• billconan confirms that "Smooth zooming was the main thing I focused on optimizing."
• On the mobile experience, typpilol notes, "The mobile site works well. Quite fast and snappy."

However, a bug related to the redaction tool was identified:

• lucfranken reports, "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."
• bobsingor acknowledges the bug and clarifies the intended behavior on mobile: "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!"

PDF Engine Choice and Attribution

The choice of PDFium as the underlying rendering engine and the necessary attribution for its developers is a point of discussion.

• lysace raises a concern about crediting the original developers: "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."
• bobsingor responds by confirming that attribution is provided: "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."
• lysace suggests further improving visibility: "That’s neat. I would also mention it in the README.md."

Annotations and Features

The support for PDF annotations is a key feature discussed, with users reporting mixed experiences and the developer clarifying the current capabilities.

• looperhacks tries a PDF with an annotation, stating, "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?"
• bobsingor details the current annotation support: "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 happen to know what annotation type it is in your PDF? I’m curious."
• gurjeet provides specific feedback on browser compatibility for annotations: "Annotations didn't work at all in Fierfox, but all annotation types (underline, highlight, etc.) worked as expected in Chrome."
• bobsingor acknowledges this cross-browser issue: "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."
• majkinetor notes that the viewer seems to have "some different features, like annotation comments," suggesting it offers more than basic annotation rendering.
• timhigins expresses interest in programmatically manipulating annotations: "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?"

Licensing and Compliance

The licensing of the project, particularly in relation to the underlying PDFium engine, is a critical point of discussion.

• gorgoiler expresses appreciation for the generous MIT license: "MIT license is generous. Good for you, and thanks!"
• bobsingor states their intention: "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."
• However, layer8 points out a potential licensing conflict: "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."
• bobsingor quickly addresses this by submitting a pull request to ensure compliance: "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!"

Development Process and Future Plans

User billconan shares insights into their own development choices, drawing parallels to bobsingor's project.

• billconan mentions opting for a native C++ solution with Metal rendering over hybrid approaches like Electron or Tauri to "avoid IPC overhead and get the best possible performance," choosing this despite preferring web UI development: "I did consider a hybrid approach with Electron or Tauri, but dropped the idea to avoid IPC overhead and get the best possible performance."
• bobsingor reveals the project's development timeline: "Thanks! I’ve been working on it for about 7 months now."
• slig inquires about specific future features: "I know this might be way out of scope, but do you have any plans for a 'flipbook' visualization?"
• bobsingor indicates openness to this feature: "Not on the roadmap yet, but I’d definitely be open to adding it if more people are interested."
• timhigins highlights interest in the headless React library: "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."

Alternative Perspectives and General Commentary

Some comments offer broader perspectives or tangential thoughts on PDF usage and the existence of similar projects.

• wewewedxfgdf asks about the motivation for building this project given the existence of mozilla/pdf.js: "I'm curious to know why you built this when the Mozilla PDF viewer exists: https://github.com/mozilla/pdf.js." This sentiment is echoed by others who are simply "curious."
• stronglikedan offers a nuanced distinction: "Nitpick, but Viewer is free and always has been. You're building a free alternative to Acrobat."
• lerp-io takes an extreme stance: "the best solution is simply to not use PDF."

Finally, a technical error related to undefined TouchEvent was reported:

• grimgrin posts a traceback: <pre>Uncaught ReferenceError: TouchEvent is not defined</pre> and provides a link to MDN documentation for context.