PaperPilot – Zero-Cloud, Pure-Rust PDF Engine with WASM and MCP
vardhan1237 · 139 points · 32 comments · 6 часов назад · Open original
Comments
5 preview comments · loading full thread
Log in to use comments
Log in to h4cker, then connect Hacker News to publish comments.
FSfschuett56 минут назад
Why do people try to vibecode PDF engines that already exist in Rust? https://github.com/yfedoseev/pdf_oxide which this project builds on completely misses https://github.com/fschutt/printpdf which was already developed with tons of fixes over years (both with and without AI). MIT license and also builds on WASM with a demo running on https://fschutt.github.io/printpdf/
One Google search (yeah I'm old, sorry, nobody "Googles" anymore) for "rust pdf library" shows this. Yet people now redo and redo and redo everything again just to have "their" semi-broken copy of a HTML -> PDF renderer (and then run into the same edge cases that were already fixed before). There are lots of edge cases in typography especially, I recently had a lot of fixes as I was trying to ocr-and-cleanup a 1732 scan of some books with Claude auto-extracting the font. There were a ton of edge cases in the layout, esp. related to column, footnote and sidebar handling, or things like "Hebrew RTL text accidentally disappears if text breaks weirdly", "1-bit image compression", etc.
I have nothing against AI, I use it heavily myself, but what is annoying is people completely ignoring the years of work of existing projects that do the exact same thing - instead of just forking, but instead re-tokenizing the exact same work again. Most likely the author didn't research "does this already exist" and that's annoying, then you get 100 of similar projects reinventing the world with tokens again and again. Sometimes its beneficial and can lead to faster exploration of new approaches, but in most cases its not and misses edge cases that were solved before.
LALatitude79738 минут назад
I'd like to point out Bento PDF: https://www.bentopdf.com/
It runs in the browser, is private and no-fuss. You can also host it locally if you like.
PIpinyencheng9 минут назад
RUST PDF engine have already exist for months. People should stop building wheels. People should contribute to great projects that already exists. Submit PR instead of making another again.
SUSurac3 часа назад
I use mostly typst for pdf generating today i have written different frontends and connectors to transform everything into typ files and templates. I eben use it with sphinx as a backend
COcolesantiago5 часов назад
Is this PDF engine vibe-coded and derived from reading the MuPDF source code? (Written from C to Rust) I see some slight references to MuPDF in certain places.
If it is you should disclose it and the license should be AGPLv3 instead of Apache.
Comments
5 preview comments · loading full threadLog in to h4cker, then connect Hacker News to publish comments.
Why do people try to vibecode PDF engines that already exist in Rust? https://github.com/yfedoseev/pdf_oxide which this project builds on completely misses https://github.com/fschutt/printpdf which was already developed with tons of fixes over years (both with and without AI). MIT license and also builds on WASM with a demo running on https://fschutt.github.io/printpdf/ One Google search (yeah I'm old, sorry, nobody "Googles" anymore) for "rust pdf library" shows this. Yet people now redo and redo and redo everything again just to have "their" semi-broken copy of a HTML -> PDF renderer (and then run into the same edge cases that were already fixed before). There are lots of edge cases in typography especially, I recently had a lot of fixes as I was trying to ocr-and-cleanup a 1732 scan of some books with Claude auto-extracting the font. There were a ton of edge cases in the layout, esp. related to column, footnote and sidebar handling, or things like "Hebrew RTL text accidentally disappears if text breaks weirdly", "1-bit image compression", etc. I have nothing against AI, I use it heavily myself, but what is annoying is people completely ignoring the years of work of existing projects that do the exact same thing - instead of just forking, but instead re-tokenizing the exact same work again. Most likely the author didn't research "does this already exist" and that's annoying, then you get 100 of similar projects reinventing the world with tokens again and again. Sometimes its beneficial and can lead to faster exploration of new approaches, but in most cases its not and misses edge cases that were solved before.
I'd like to point out Bento PDF: https://www.bentopdf.com/ It runs in the browser, is private and no-fuss. You can also host it locally if you like.
RUST PDF engine have already exist for months. People should stop building wheels. People should contribute to great projects that already exists. Submit PR instead of making another again.
I use mostly typst for pdf generating today i have written different frontends and connectors to transform everything into typ files and templates. I eben use it with sphinx as a backend
Is this PDF engine vibe-coded and derived from reading the MuPDF source code? (Written from C to Rust) I see some slight references to MuPDF in certain places. If it is you should disclose it and the license should be AGPLv3 instead of Apache.