vardhan1237

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.

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/

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!

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.