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 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
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.
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.
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.
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.
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.
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.
It runs in the browser, is private and no-fuss. You can also host it locally if you like.
If it is you should disclose it and the license should be AGPLv3 instead of Apache.
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)
""" 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.
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!