vardhan1237

Thanks for checking out the docs! We used a hybrid workflow: Antigravity IDE paired with Jules for asynchronous sub-tasks (like spinning up isolated unit tests and docs in parallel containers).

Having a strict test-first harness where every PR has to run against real PDF byte fixtures (zero mocks) and compile across CLI, WASM, and MCP kept the codebase consistent even when moving fast.

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.

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.