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.
Is it people ignoring years of work, or the AI they're using? The people haven't read and digested the human history of PDF engine development, that's their excuse, what's AI's?
> Search is so bad and LLM so good that it's faster and easier to re-implement than reuse.
This is a scary level of AI mania.
Even if you're being assisted by the best frontier model, there is no way that reimplementing a PDF engine from scratch is faster than just using the one that's already there. AI-driven coding still takes time and tokens. A web search takes maybe 60 seconds to search and find the existing implementations?
You could even tell the LLM to configure (or even fork) one of the existing implementations for you, and that would still be way faster than a from-scratch implementation.
LLMs will miss a lot of edge cases. This is critical for a library that parses PDFs. Ask it to review the code for issues and by the 20th time you ask, it still will find issues. How's that faster (or safer)?
I use AI heavily but it's not this omnipresent deity that knows everything at all times.
Redoing is almost free today, you can try to redo a lot of stuff, try to gain traction/publicity and maybe that will be your solution that will stick. People were trying this strategy with a lot of stuff (think smartphone cases) but in case of software this is soo easy and dead cheap.
I see the outbreak of PDF readers, AI TUI harnesses, etc.
You may have missed the bulk of the "free" ride: ChatGPT Pro 200 is both being imminently nerfed (even for those who signed up before) and reaching the end of a month of reset candy as they quell that backlash/end a month of "ailu major features or resets". Yes, it was $200... but hear me out first!
In the last 5 days alone I've had the equivalent of 2+ years of ChatGPT Plus Codex quota given for free via resets. I literally leave my PC running in Codex with 8+ Sol 6.1 Max sessions jamming away most of the day writing a desktop environment from scratch (and other things) just because the reset tokens will evaporate if I don't use them. I've even had days with > 1 billion tokens used where it was reset by the morning.
That said, who knows what free ride will appear with AI capital next month!
The more optimistic hope is that actual prices continue to drop at the rate they have been and then by the time the subsidization runs out (even if that's not far from now) it's because there is nothing for the chickens to come home and roost to anymore.
After all, a year ago and doing these same tasks would just fall on its face. The hard part of the problem is solved, now it's not even "do LLMs continue to get better" but "do LlMs keep getting cheaper".
You got to give it to the AI mega corporations’ pr efforts. They have convinced people that paying them to regenerate something they can get for free, is a sensible idea.
Like this case, the open source project here could be used as a base for further development by AI!
I can't wait to exploit all of the known and new pdf CVEs from all these new vibe coded pdf engines. Unless they managed to put in the secret phrase "and don't make any mistakes, especially on security!"
Huge respect for your work on printpdf, and thank you for chiming in!
When we evaluated the Rust PDF landscape, printpdf was actually one of the first crates we looked at for PDF generation. The reason we opted for a stack centered around lopdf and pdf-writer was architectural: PaperPilot's primary focus is heavy manipulation and non-destructive AST transformation of existing, arbitrary, often malformed real-world PDFs (re-ordering cross-reference tables, granular /P permission bitmask hashing, raw object streams, page imposition, booklet folding, and outline splitting).
For document synthesis (HTML/Markdown to PDF), typography and edge-cases (like the RTL/footnote issues you mentioned) are notoriously hard, and we'd love to learn from or collaborate with printpdf's battle-tested approaches there. Thank you for the feedback and all your contributions to Rust's PDF ecosystem!
> Why do people try to vibecode PDF engines that already exist in Rust?
Nothing surprising here; pre-2022/2023, Rust was used primarily for rewriting things (compared to, for example, Go, which was used to write new things, not replacements).
I don't find it surprising that the pattern is continuing.
It's not a rust specific thing at all, HN has had it's share of “<something> but written in JavaScript” (as well as in Go[1]) back in the day, it's just a common thing when a language becomes popular, as their are more people wanting to show off that they did something than people with genuinely original ideas worth posting on HN.
It's not that Rust or Go aren't used to write new things, it's just that the bar for reaching the HN front page with new things is much higher
than for mere copycats.
> Rust was used primarily for rewriting things (compared to, for example, Go, which was used to write new things, not replacements
How could you possibly know this, for either languages?
FWIW, I've only worked and written greenfield software with Rust, and have only worked professionally with Golang to replace existing services. I'm sure I'm not alone in this, nor in the complete opposite. But I don't think either of us could say how either of the languages or "primarily used", that's a bit too much.
> Anecdotally, it's not representative of your experience.
I'm glad you got the gist of my comment :)
> But... Rewrite-it-in-Rust is a meme, while rewrite in Go is not.
Today no, but it definitely was when it first became popular, "X but in Go" was fairly common on the HN frontpage and elsewhere. Just like "X but in Ruby" used to be a thing too, but isn't anymore.
Because this isn't a library, but an ambitious commercial headed [1] tool. If your needs and use cases match the feature set they're aiming for, and their market research and projections are able to undercut Adobe by an order of magnitude, then they might be on to something.
> Strategic Vision: Evolve PaperPilot from a best-in-class PDF workstation into the Universal Document Operating System for humans and AI agents. [2]
Completely agree, it doesn't help that the models all seem to promote this behavior by writing everything from scratch most of the time.
I explicitly start most programming projects with a request for existing libraries and explicit instructions to the model to prefer using them and keep our logic exclusively to what we need beyond that.
People are forgetting and/or don't realize that just because the actual generation is zero cost does not mean the code is zero cost. Every line of bespoke code is a liability. Every piece of duplicative software you produce for no reason other than "this one is mine" is polluting the ecosystem and creating a noisy landscape in which such problems will just get worse. We are seeing the complete erosion of collective contribution models which has negative implications for the collective maintenance and enhancement of shared knowledge over time.
I just ran an security analysis on the repo. As is, it's not looking great (again nothing against vibe/agentic coded projects) the lack of security consideration is astonishing (not suggesting a malice). Definitely NOT production ready.
Context: about 98% of the commits are by AI bots (Antigravity, Google Jules).
That explains the bugs below.
Security bugs
1. High: the local web API lets any website use the user's files.
- paperpilot-gateway/src/server.rs:95-98 allows requests from any website, and
there's no login or authentication.
- POST /api/v1/pdf/mcp-exec (handlers.rs:233) runs any tool with any file path
on the machine.
- So while the API is running, any web page the user visits can make it
overwrite files with PDFs, create folders, and read back text from any local
PDF.
- In the desktop app the user has to switch the API on. But docker-compose.yml
opens it to the network with no authentication.
- There's also no limit on request size (usize::MAX), so one huge request can
exhaust memory.
2. High: a malicious document can run code in the desktop app.
- Search results display text from the user's own documents as raw HTML
without escaping it:
- WorkspaceSearchModal.svelte:297
- workspaceSearch.ts:84
- WorkspaceSearchModal.svelte:118
- The app has no Content Security Policy, and lets its window read any file on
disk (tauri.conf.json:28-33, scope "**").
- So a PDF or DOCX carrying an <img onerror=…> payload could read any local
file and send it out once the user searches it.
3. Medium: downloaded models and add-on packs are never verified.
- There's no checksum check on models (ai_commands.rs, ocr_commands.rs). Some
come straight from the repo's live main branch, so whatever lands there
ships to users.
- Pack downloads (pack_commands.rs:147-151) put pack_id straight into the file
path. A value containing ../ writes outside the app's data folder.
- Packs come from huggingface.co/paperpilot/packs, an account I didn't confirm
the project owns.
4. Medium/Low: the protection against fetching internal addresses can be
bypassed (paperpilot-core/src/url_fetch.rs:24-40).
- It only checks IP addresses typed directly into the URL, not what a domain
name resolves to.
- It follows redirects, so a public URL can redirect to an internal one.
- IPv6 addresses ([::1]), 0.0.0.0 and the 100.64.0.0/10 range get through.
- The impact is limited because the response must start with %PDF.
5. Low: CI supply chain.
- release.yml installs wasm-pack via curl | sh.
- GitHub Actions are pinned to version tags, not commit hashes.
- The Android build ignores the lockfile (--no-frozen-lockfile).
Maybe people are having fun reinventing the wheel? Maybe they want to try other ways to solve the same problem or pick different trade-offs. Maybe they don't like the license, plenty of software has been written from scratch just to avoid the license of existing software.
Maybe because yours is listed as having its latest release five years ago, and the one it builds upon only two months ago? Not saying this is the only metric that counts, bit it is easy to check when comparing.
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
How do you use it with i18n and theming and templates? Do you define all of these outside of typst and (e.g.) add a shadow file to the typst compiler?
Asking because I've recenly been doing something similar, but since my typst files are templates, which with the same inputs can differ and may need different translations as well, I've written a small i18n library in typst (but I guess you could require a set of translations to be present with a given typst file as well).
U have a typst template file mostly containig functions and variable defs. Then i have a docutil -> typst rewriter that makes use of the functions of the the template. i18n is a non problem for me, because i have source files containig the correct text, but i have created ttf fonts containing may international glyphs using fontutils. As sphinx and typst support unicode it just works. the PDF are then postprocessed and all glyphs not used are striped out of the pdf, also some pdf streams are removed to shrink the pdf
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.
been using https://github.com/SimonBure/presse for all my pdf needs for a while - works great thus far (not affiliated); simple cli is in most case all you will ever need
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.
Unless they meant vaguely similar code (which I can't judge), the only mentions of mupdf are in the AI instructions:
> **The Opportunity:** Capturing the high-growth enterprise AI engineering market by replacing bloated, slow Python extraction pipelines (`Unstructured.io`, `Docling`, `Marker`, `LlamaParse`, `PyMuPDF4LLM`) with a pure-Rust, sub-10ms, multi-format ingestion kernel.
- This structure guarantees that if we ever swap the PDF engine to `pdfium` or `mupdf`, not a single line of business logic in `paperpilot-core` or CLI tools will need to be rewritten.
> Directly captures the high-growth AI Engineering & RAG pipeline market (displacing bloated Python stacks like Docling, Marker, PyMuPDF4LLM, and Camelot) with sub-10ms, pure-Rust, on-device parsing.
| A.2.5 | `MuPdfBackend` adapter (Future) | Use MuPDF for OCR-heavy workflows via FFI |
Without context, just reading the above, it sounds more like they're attempting to create an abstract interface for pluggable PDF engines, which shouldn't pose any licensing issues assuming all the licenses are AGPL v3 compatible and builds that include AGPL engines are only used under the terms of the AGPL, sort of like how ffmpeg works with the "--enable-gpl" switch.
Definitely not! There is zero MuPDF code, FFI, or transpilation in PaperPilot.
The core PDF parsing and AST manipulation is built on pure Rust libraries: lopdf (0.45), pdf-writer, hayro, and image. All of these are Apache 2.0 or MIT licensed.
Any mention of MuPDF in the documentation/planning notes was strictly part of an architectural trade-off analysis (evaluating existing Python/C extraction pipelines like PyMuPDF vs. pure Rust). The entire crate stack in paperpilot-pdf is 100% Apache 2.0 / MIT clean.
i like the interface but the bugs are irritating:
1)click on a text box (using IRS form 1040 as an example), change the character spacing from the default (0) to something then change it back to zero. You dont get the original text
2) add a text box, you cant move it around even when the 4 way arrows are showing when you hover over it or even try to move it using the arrow keys
3) add a text box, enter text, highlight it, change line spacing, the spacing changes but the number in the box stays at 1.25
4) character spacing and word spacing dont work
5) last update a year ago
Both are actually already supported! We have pdf_decrypt (which unlocks password-protected PDFs given the password) and pdf_sign for applying cryptographic signatures, as well as pdf_validate_signatures for verifying certificates.
I think there's a difference between a standard PDF viewer and basic functionality, vs a full PDF authoring suite like Adobe. For some of the basic features in one of the comments, I'm not quite sure how tried and tested tools that are simple like Foxit PDF don't fit the bill for most things. Unless you're trying to process gobs of PDFs in headless mode or do some sort of analysis... eh.
Is there a real use case for manually authoring a PDF directly? I assumed everyone would either use a word processor or some other tool that exports as pdf rather than editing a pdf as if it was a word doc.
Yes! We have an official desktop GUI for macOS, Windows, and Linux built with Tauri 2 and Svelte 5 (with native dark mode, visual diff, and a visual pipeline builder). We also have the full browser-based GUI running client-side via WASM at https://usepaperpilot.com/
FYI the box with the tool you've selected (where you upload and set parameters) is way too small on mobile. By scrolling you can use it, but you can only see a tiny bit of the interface at a time. Firefox on Android.
Love the web interface! But can it be done better?
First, how do you "sign" a PDF using this tool?
If you're going to build this, can you find a small, even tiny model that has decent tool calling and, effectively turn that in combination with this tool into a single HTML page that I can use everywhere?
Literally something I could save on a work laptop or cloud desktop and would actually work (even if it would be slow, it'd still be a great improvement)
In case you don't have showdead on, the OP writes:
"""
I built PaperPilot because I was frustrated by the privacy trade-offs of modern PDF utilities.
Whenever you need to split, merge, compress, or sign a confidential document (tax forms, legal contracts, medical paperwork) using online tools, your files are transmitted to a third-party server. Most "free" tools retain copies or run in closed-source cloud environments.
PaperPilot is a 100% zero-cloud, local-first engine written in pure Rust (built on top of lopdf, pdf-writer, and image). 0 bytes are ever sent to an external server.
Key aspects of the project:
1. Penta-Interface Architecture: Instead of building just another web app or CLI, the same core Rust operations run across 5 surfaces: - Terminal CLI: High-throughput local processing and bash scripting. - Local Desktop App: Native cross-platform GUI built with Tauri 2 and Svelte 5. - Client-Side Web: Runs 100% inside your browser via WebAssembly (https://usepaperpilot.com/). - REST / Gateway API: Standalone local daemon (localhost:7823) for local microservices. - Model Context Protocol (MCP): Connects local AI agents (Claude Desktop, Cursor, OpenCode) directly to local PDF tools so LLMs can inspect, redact, and sign PDFs on disk without cloud upload.
2. Capabilities (75+ Tools): - Standard operations: Merge, split, rotate, reorder, burst, booklet imposition, and N-up grid. - Privacy & Compliance: Local PII regex redaction (SSNs, cards, emails), metadata striping, and digital signature verification. - Document Extraction: PDF to structured Markdown tables (no coordinate loss), PDF to JSON, and pure-Rust layout analysis. - Offline RAG: Embedded vector store (libsql_vector) with an actionable visual citation canvas.
3. Performance & License: - Average operation latency is ~20ms to 130ms. - 100% Free and Open Source under the Apache 2.0 license.
> Native cross-platform GUI built with Tauri 2 and Svelte 5
That's not native, and if you pointed it out to the LLM that wrote this, it would agree. It's just dumb so it didn't think of the fact that that's entirely the wrong term.
I built PaperPilot because I was frustrated by the privacy trade-offs of modern PDF utilities.
Whenever you need to split, merge, compress, or sign a confidential document (tax forms, legal contracts, medical paperwork) using online tools, your files are transmitted to a third-party server. Most "free" tools retain copies or run in closed-source cloud environments.
PaperPilot is a 100% zero-cloud, local-first engine written in pure Rust (built on top of lopdf, pdf-writer, and image). 0 bytes are ever sent to an external server.
Key aspects of the project:
1. Penta-Interface Architecture:
Instead of building just another web app or CLI, the same core Rust operations run across 5 surfaces:
- Terminal CLI: High-throughput local processing and bash scripting.
- Local Desktop App: Native cross-platform GUI built with Tauri 2 and Svelte 5.
- Client-Side Web: Runs 100% inside your browser via WebAssembly (https://usepaperpilot.com/).
- REST / Gateway API: Standalone local daemon (localhost:7823) for local microservices.
- Model Context Protocol (MCP): Connects local AI agents (Claude Desktop, Cursor, OpenCode) directly to local PDF tools so LLMs can inspect, redact, and sign PDFs on disk without cloud upload.
2. Capabilities (75+ Tools):
- Standard operations: Merge, split, rotate, reorder, burst, booklet imposition, and N-up grid.
- Privacy & Compliance: Local PII regex redaction (SSNs, cards, emails), metadata striping, and digital signature verification.
- Document Extraction: PDF to structured Markdown tables (no coordinate loss), PDF to JSON, and pure-Rust layout analysis.
- Offline RAG: Embedded vector store (libsql_vector) with an actionable visual citation canvas.
3. Performance & License:
- Average operation latency is ~20ms to 130ms.
- 100% Free and Open Source under the Apache 2.0 license.
I really like the approach with WASM and the browser sandbox. That alone makes this very usable. iam also working on an agent harnes in the browser sandbox called "hermit" using a local inference endpoint. It runs Python in WASM with a virtual file system.
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.
Is it people ignoring years of work, or the AI they're using? The people haven't read and digested the human history of PDF engine development, that's their excuse, what's AI's?
The readme says: "Small and dependency-light. Pure Rust, built on lopdf, pdf_oxide, rten, and friends.", and paperpilot-pdf/Cargo.toml confirms that.
> One Google search (yeah I'm old, sorry, nobody "Googles" anymore)
Maybe that's your answer. Search is so bad and LLM so good that it's faster and easier to re-implement than reuse.
The only thing that slows down the new paradigm is the apparent requirement of posting the output to HN so others will find it.
That irony is not lost on me.
Fast, easy, safe. Choose two
Vibecoding your own PDF engine is choosing none of them.
> Search is so bad and LLM so good that it's faster and easier to re-implement than reuse.
This is a scary level of AI mania.
Even if you're being assisted by the best frontier model, there is no way that reimplementing a PDF engine from scratch is faster than just using the one that's already there. AI-driven coding still takes time and tokens. A web search takes maybe 60 seconds to search and find the existing implementations?
You could even tell the LLM to configure (or even fork) one of the existing implementations for you, and that would still be way faster than a from-scratch implementation.
LLMs will miss a lot of edge cases. This is critical for a library that parses PDFs. Ask it to review the code for issues and by the 20th time you ask, it still will find issues. How's that faster (or safer)?
I use AI heavily but it's not this omnipresent deity that knows everything at all times.
Redoing is almost free today, you can try to redo a lot of stuff, try to gain traction/publicity and maybe that will be your solution that will stick. People were trying this strategy with a lot of stuff (think smartphone cases) but in case of software this is soo easy and dead cheap.
I see the outbreak of PDF readers, AI TUI harnesses, etc.
> Redoing is almost free today
Can I get some of those free tokens you’re having?
You may have missed the bulk of the "free" ride: ChatGPT Pro 200 is both being imminently nerfed (even for those who signed up before) and reaching the end of a month of reset candy as they quell that backlash/end a month of "ailu major features or resets". Yes, it was $200... but hear me out first!
In the last 5 days alone I've had the equivalent of 2+ years of ChatGPT Plus Codex quota given for free via resets. I literally leave my PC running in Codex with 8+ Sol 6.1 Max sessions jamming away most of the day writing a desktop environment from scratch (and other things) just because the reset tokens will evaporate if I don't use them. I've even had days with > 1 billion tokens used where it was reset by the morning.
That said, who knows what free ride will appear with AI capital next month!
You’re right. As you noted, “free” is not the same as heavily subsidized. The chickens will have to come home to roost.
The more optimistic hope is that actual prices continue to drop at the rate they have been and then by the time the subsidization runs out (even if that's not far from now) it's because there is nothing for the chickens to come home and roost to anymore.
After all, a year ago and doing these same tasks would just fall on its face. The hard part of the problem is solved, now it's not even "do LLMs continue to get better" but "do LlMs keep getting cheaper".
LLM performance increases substantially when the exact software you’re writing is already in the training data.
I was thinking the same thing when another PDF library popped up in the .NET subreddit a few hours before this post.
You got to give it to the AI mega corporations’ pr efforts. They have convinced people that paying them to regenerate something they can get for free, is a sensible idea.
Like this case, the open source project here could be used as a base for further development by AI!
I can't wait to exploit all of the known and new pdf CVEs from all these new vibe coded pdf engines. Unless they managed to put in the secret phrase "and don't make any mistakes, especially on security!"
> 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/
It seems like fschutt/printpdf is your project. You should definitely at least disclose it in your comment, if that's the case.
It‘s my repo yeah, I thought that was obvious from my username, sorry.
It is obvious
Huge respect for your work on printpdf, and thank you for chiming in!
When we evaluated the Rust PDF landscape, printpdf was actually one of the first crates we looked at for PDF generation. The reason we opted for a stack centered around lopdf and pdf-writer was architectural: PaperPilot's primary focus is heavy manipulation and non-destructive AST transformation of existing, arbitrary, often malformed real-world PDFs (re-ordering cross-reference tables, granular /P permission bitmask hashing, raw object streams, page imposition, booklet folding, and outline splitting).
For document synthesis (HTML/Markdown to PDF), typography and edge-cases (like the RTL/footnote issues you mentioned) are notoriously hard, and we'd love to learn from or collaborate with printpdf's battle-tested approaches there. Thank you for the feedback and all your contributions to Rust's PDF ecosystem!
> Why do people try to vibecode PDF engines that already exist in Rust?
Nothing surprising here; pre-2022/2023, Rust was used primarily for rewriting things (compared to, for example, Go, which was used to write new things, not replacements).
I don't find it surprising that the pattern is continuing.
It's not a rust specific thing at all, HN has had it's share of “<something> but written in JavaScript” (as well as in Go[1]) back in the day, it's just a common thing when a language becomes popular, as their are more people wanting to show off that they did something than people with genuinely original ideas worth posting on HN.
It's not that Rust or Go aren't used to write new things, it's just that the bar for reaching the HN front page with new things is much higher than for mere copycats.
[1]: https://hn.algolia.com/?q=written+in+Go
> Rust was used primarily for rewriting things (compared to, for example, Go, which was used to write new things, not replacements
How could you possibly know this, for either languages?
FWIW, I've only worked and written greenfield software with Rust, and have only worked professionally with Golang to replace existing services. I'm sure I'm not alone in this, nor in the complete opposite. But I don't think either of us could say how either of the languages or "primarily used", that's a bit too much.
Anecdotally, it's not representative of your experience.
But... Rewrite-it-in-Rust is a meme, while rewrite in Go is not.
> Anecdotally, it's not representative of your experience.
I'm glad you got the gist of my comment :)
> But... Rewrite-it-in-Rust is a meme, while rewrite in Go is not.
Today no, but it definitely was when it first became popular, "X but in Go" was fairly common on the HN frontpage and elsewhere. Just like "X but in Ruby" used to be a thing too, but isn't anymore.
Lots of people do lots of things.
Because this isn't a library, but an ambitious commercial headed [1] tool. If your needs and use cases match the feature set they're aiming for, and their market research and projections are able to undercut Adobe by an order of magnitude, then they might be on to something.
> Strategic Vision: Evolve PaperPilot from a best-in-class PDF workstation into the Universal Document Operating System for humans and AI agents. [2]
[1] https://github.com/KrushnaVardhanReddy/PaperPilot/blob/main/...
[2] https://github.com/KrushnaVardhanReddy/PaperPilot/blob/main/...
„3.6 Gemini? He‘s delusional, take him to the infirmary.“
Completely agree, it doesn't help that the models all seem to promote this behavior by writing everything from scratch most of the time.
I explicitly start most programming projects with a request for existing libraries and explicit instructions to the model to prefer using them and keep our logic exclusively to what we need beyond that.
People are forgetting and/or don't realize that just because the actual generation is zero cost does not mean the code is zero cost. Every line of bespoke code is a liability. Every piece of duplicative software you produce for no reason other than "this one is mine" is polluting the ecosystem and creating a noisy landscape in which such problems will just get worse. We are seeing the complete erosion of collective contribution models which has negative implications for the collective maintenance and enhancement of shared knowledge over time.
As someone whose commercial software needs to ingest PDFs: I stay away from things like lopdf because of how they fail to handle broken pdfs.
The first project you linked explicitly calls out broken pdf handling.
And unfortunately, these posts goes on frontpage, because AI, but no ai posts are largly ignored.
I just want a really exhaustive one in .NET land to be honest, some of these paid companies are getting wild with their pricing schemes.
Ditto.
I just ran an security analysis on the repo. As is, it's not looking great (again nothing against vibe/agentic coded projects) the lack of security consideration is astonishing (not suggesting a malice). Definitely NOT production ready.
Possibly using AI as a search engine which it's not always great at, and then deciding why not.
Maybe people are having fun reinventing the wheel? Maybe they want to try other ways to solve the same problem or pick different trade-offs. Maybe they don't like the license, plenty of software has been written from scratch just to avoid the license of existing software.
Maybe because yours is listed as having its latest release five years ago, and the one it builds upon only two months ago? Not saying this is the only metric that counts, bit it is easy to check when comparing.
https://github.com/KrushnaVardhanReddy/PaperPilot/commit/63d...
I like to check out everyone's first commits :)
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
How do you use it with i18n and theming and templates? Do you define all of these outside of typst and (e.g.) add a shadow file to the typst compiler?
Asking because I've recenly been doing something similar, but since my typst files are templates, which with the same inputs can differ and may need different translations as well, I've written a small i18n library in typst (but I guess you could require a set of translations to be present with a given typst file as well).
I'm interested in knowing how you do the i18n in Typst. Seems interesting
U have a typst template file mostly containig functions and variable defs. Then i have a docutil -> typst rewriter that makes use of the functions of the the template. i18n is a non problem for me, because i have source files containig the correct text, but i have created ttf fonts containing may international glyphs using fontutils. As sphinx and typst support unicode it just works. the PDF are then postprocessed and all glyphs not used are striped out of the pdf, also some pdf streams are removed to shrink the pdf
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.
the gif in the readme has visibly broken ui (the text on the right in the header is not vertically aligned)
i'm not convinced a human has ever actually looked at this project; this must be the work of someone's overzealous openclaw agent or something.
I too have created a set of tools which runs in local. Can use it here https://toolbit.app/ and the repo is at https://github.com/alwin-augustin/toolbit . Working on the desktop apps. The mac silicon app is ready and working.
been using https://github.com/SimonBure/presse for all my pdf needs for a while - works great thus far (not affiliated); simple cli is in most case all you will ever need
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.
Licenses are so yesterday. /s
Seriously though, can you list some examples?
Unless they meant vaguely similar code (which I can't judge), the only mentions of mupdf are in the AI instructions:
That's not vague. That's derivation. To use an AI-ism.
Without context, just reading the above, it sounds more like they're attempting to create an abstract interface for pluggable PDF engines, which shouldn't pose any licensing issues assuming all the licenses are AGPL v3 compatible and builds that include AGPL engines are only used under the terms of the AGPL, sort of like how ffmpeg works with the "--enable-gpl" switch.
It's using hayro in Rust
Definitely not! There is zero MuPDF code, FFI, or transpilation in PaperPilot.
The core PDF parsing and AST manipulation is built on pure Rust libraries: lopdf (0.45), pdf-writer, hayro, and image. All of these are Apache 2.0 or MIT licensed.
Any mention of MuPDF in the documentation/planning notes was strictly part of an architectural trade-off analysis (evaluating existing Python/C extraction pipelines like PyMuPDF vs. pure Rust). The entire crate stack in paperpilot-pdf is 100% Apache 2.0 / MIT clean.
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.
i like the interface but the bugs are irritating: 1)click on a text box (using IRS form 1040 as an example), change the character spacing from the default (0) to something then change it back to zero. You dont get the original text 2) add a text box, you cant move it around even when the 4 way arrows are showing when you hover over it or even try to move it using the arrow keys 3) add a text box, enter text, highlight it, change line spacing, the spacing changes but the number in the box stays at 1.25 4) character spacing and word spacing dont work 5) last update a year ago
Would be useful to have a remove password feature (for a known password) and support for adding signatures
Both are actually already supported! We have pdf_decrypt (which unlocks password-protected PDFs given the password) and pdf_sign for applying cryptographic signatures, as well as pdf_validate_signatures for verifying certificates.
I'm amazed to learn from these comments that there are so many local PDF solutions (and opinions on them).
I started building things like this as browser extensions to make the hosting simpler.
Can I use it with Open-Webui instead of Apache Tika?
I think there's a difference between a standard PDF viewer and basic functionality, vs a full PDF authoring suite like Adobe. For some of the basic features in one of the comments, I'm not quite sure how tried and tested tools that are simple like Foxit PDF don't fit the bill for most things. Unless you're trying to process gobs of PDFs in headless mode or do some sort of analysis... eh.
Is there a real use case for manually authoring a PDF directly? I assumed everyone would either use a word processor or some other tool that exports as pdf rather than editing a pdf as if it was a word doc.
Modifying existing PDFs in my limited experience is to make some changes or remove security or add a stamp and it make it seem official.
The feature i like about this is privacy focused
Sorry I just realized it is private running in browser only. thats the feature i am looking for
Nice work.
interesting，but will it have official GUI？
Yes! We have an official desktop GUI for macOS, Windows, and Linux built with Tauri 2 and Svelte 5 (with native dark mode, visual diff, and a visual pipeline builder). We also have the full browser-based GUI running client-side via WASM at https://usepaperpilot.com/
FYI the box with the tool you've selected (where you upload and set parameters) is way too small on mobile. By scrolling you can use it, but you can only see a tiny bit of the interface at a time. Firefox on Android.
Love the web interface! But can it be done better?
First, how do you "sign" a PDF using this tool?
If you're going to build this, can you find a small, even tiny model that has decent tool calling and, effectively turn that in combination with this tool into a single HTML page that I can use everywhere?
Literally something I could save on a work laptop or cloud desktop and would actually work (even if it would be slow, it'd still be a great improvement)
In case you don't have showdead on, the OP writes:
""" I built PaperPilot because I was frustrated by the privacy trade-offs of modern PDF utilities.
Whenever you need to split, merge, compress, or sign a confidential document (tax forms, legal contracts, medical paperwork) using online tools, your files are transmitted to a third-party server. Most "free" tools retain copies or run in closed-source cloud environments.
PaperPilot is a 100% zero-cloud, local-first engine written in pure Rust (built on top of lopdf, pdf-writer, and image). 0 bytes are ever sent to an external server.
Key aspects of the project:
1. Penta-Interface Architecture: Instead of building just another web app or CLI, the same core Rust operations run across 5 surfaces: - Terminal CLI: High-throughput local processing and bash scripting. - Local Desktop App: Native cross-platform GUI built with Tauri 2 and Svelte 5. - Client-Side Web: Runs 100% inside your browser via WebAssembly (https://usepaperpilot.com/). - REST / Gateway API: Standalone local daemon (localhost:7823) for local microservices. - Model Context Protocol (MCP): Connects local AI agents (Claude Desktop, Cursor, OpenCode) directly to local PDF tools so LLMs can inspect, redact, and sign PDFs on disk without cloud upload.
2. Capabilities (75+ Tools): - Standard operations: Merge, split, rotate, reorder, burst, booklet imposition, and N-up grid. - Privacy & Compliance: Local PII regex redaction (SSNs, cards, emails), metadata striping, and digital signature verification. - Document Extraction: PDF to structured Markdown tables (no coordinate loss), PDF to JSON, and pure-Rust layout analysis. - Offline RAG: Embedded vector store (libsql_vector) with an actionable visual citation canvas.
3. Performance & License: - Average operation latency is ~20ms to 130ms. - 100% Free and Open Source under the Apache 2.0 license.
The GitHub repository is at https://github.com/KrushnaVardhanReddy/PaperPilot and the browser-based WASM sandbox is live at https://usepaperpilot.com/.
I’d love to hear your feedback on the architecture, performance benchmarks, and any edge-case PDF formats we should test against! """
Which reads very much LLM produced.
It read to me as a case of: "only webpages are software, and I'm afraid of the command line".
Really. All he wants was very easy to do already.
> It read to me as a case of: "only webpages are software, and I'm afraid of the command line".
I think you've missed this part:
> Terminal CLI: High-throughput local processing and bash scripting.
Woah, I certainly did!
I am interested in the following use case: convert the PDF to e-pub, then edit it with Calibre to fix some issues that always happen.
Currently using pandoc.
> Native cross-platform GUI built with Tauri 2 and Svelte 5
That's not native, and if you pointed it out to the LLM that wrote this, it would agree. It's just dumb so it didn't think of the fact that that's entirely the wrong term.
Hi HN,
I built PaperPilot because I was frustrated by the privacy trade-offs of modern PDF utilities.
Whenever you need to split, merge, compress, or sign a confidential document (tax forms, legal contracts, medical paperwork) using online tools, your files are transmitted to a third-party server. Most "free" tools retain copies or run in closed-source cloud environments.
PaperPilot is a 100% zero-cloud, local-first engine written in pure Rust (built on top of lopdf, pdf-writer, and image). 0 bytes are ever sent to an external server.
Key aspects of the project:
1. Penta-Interface Architecture: Instead of building just another web app or CLI, the same core Rust operations run across 5 surfaces: - Terminal CLI: High-throughput local processing and bash scripting. - Local Desktop App: Native cross-platform GUI built with Tauri 2 and Svelte 5. - Client-Side Web: Runs 100% inside your browser via WebAssembly (https://usepaperpilot.com/). - REST / Gateway API: Standalone local daemon (localhost:7823) for local microservices. - Model Context Protocol (MCP): Connects local AI agents (Claude Desktop, Cursor, OpenCode) directly to local PDF tools so LLMs can inspect, redact, and sign PDFs on disk without cloud upload.
2. Capabilities (75+ Tools): - Standard operations: Merge, split, rotate, reorder, burst, booklet imposition, and N-up grid. - Privacy & Compliance: Local PII regex redaction (SSNs, cards, emails), metadata striping, and digital signature verification. - Document Extraction: PDF to structured Markdown tables (no coordinate loss), PDF to JSON, and pure-Rust layout analysis. - Offline RAG: Embedded vector store (libsql_vector) with an actionable visual citation canvas.
3. Performance & License: - Average operation latency is ~20ms to 130ms. - 100% Free and Open Source under the Apache 2.0 license.
The GitHub repository is at https://github.com/KrushnaVardhanReddy/PaperPilot and the browser-based WASM sandbox is live at https://usepaperpilot.com/.
I’d love to hear your feedback on the architecture, performance benchmarks, and any edge-case PDF formats we should test against!
Is there anything in this project that was not already easily available with command line tools?
Yes, it's wasm. So you can run it in any browser. Super useful when no cli. Example on friend phone
Yeah, it has to be a friend phone as mine has command line via ssh (and tailscale).
who doesn't need to merge and compress bunch of pdfs on a friend phone on a saturday morning
I really like the approach with WASM and the browser sandbox. That alone makes this very usable. iam also working on an agent harnes in the browser sandbox called "hermit" using a local inference endpoint. It runs Python in WASM with a virtual file system.
https://moooff.github.io/HermitUI/hermit-agent/
So this Tool comes in very handy and will try to integrate it.
Congrats with your product, hope it works out well. Nice competitor analysis & (future) features list at https://github.com/KrushnaVardhanReddy/PaperPilot/blob/main/..., IMHO easier to read than your above list.
Question: seemingly you’re using Antigravity, an harness not many use. Please tell use about the choice of LLM and your experience with it.
Is this a port of MuPDF?
Vibecoded and Rust, name a more iconic duo.
Great work. But why you are using AI for build such a service, it does not need an AI.