Hacker News Reader

Comment by wewewedxfgdf | Hacker News Reader

I'm curious to know why you built this when the Mozilla PDF viewer exists:

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.

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.

I love when my core use case, show stopping bug is considered an edge case. ))

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

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.

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.

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 don't think there's an indication that this affects all RTL languages, just Hebrew word order in selections.

Specifically a right edge case

Nice!

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.

Reply on news.ycombinator.com