Hamza Naveedandskylar taylor-barrick
97cef90e01
* Redaction: a pattern nothing paints with any more leaves the page
A tiling pattern's cell is a content stream of its own and can draw
anything, text included. Redacting a shape filled with such a pattern
removed the fill from the page's content -- the page looked right, a
black box -- but left the pattern in /Resources /Pattern, and its cell,
with the text that was under the mark, was written into the saved file
unchanged.
The pass does not enter pattern cells, so it cannot redact inside one.
What it can do is notice that nothing paints with the pattern any more.
The graphics state now carries the fill and stroke pattern a `scn` or
`SCN` selected (and `cs`, `g`, `rg`, `k` and their stroke forms clear
it), every painting operator that survives the rewrite records the
pattern it drew with, and a pattern the page selected but no surviving
paint used leaves the page's resources.
Measured on the report's file:
before applied: 1, (SECRET) in the saved bytes
after applied: 1, no /Pattern on the page, (SECRET) gone
A pattern some surviving paint still uses is kept, and so is its cell:
with two boxes filled from one pattern and only the first marked,
patterns_removed is 0 and the resources keep the entry -- the second box
still shows the word, so it is not a leak.
Report gains patterns_removed.
Fixes #3647.
* Keep a pattern every operator that can paint with it still uses
Two defects CodeRabbit found in the first version of this change, both
of which could remove a pattern the page still draws with.
Pattern use was recorded for path painting only. Text shows with the
fill pattern too -- and with the stroke pattern in the stroking render
modes -- as do image masks and anything a form draws, and a form's
content is interpreted with a graphics state of its own, so a pattern it
inherits is never seen inside it. Content like
/Pattern cs /P0 scn 20 140 100 30 re f BT (KEEP) Tj ET
with the box redacted therefore lost the fill of text still on the page.
Every operator that can paint with the current pattern now records it:
text (except mode 3, which paints nothing, and mode 7, which only
clips), inline images, and image or form XObjects. Only path painting
knows exactly what it drew and whether the paint survived, so the others
are recorded as they are met. That can keep a pattern whose paint was in
fact all redacted, which costs an unused resource entry, while dropping
one something still draws with takes paint off the page.
/Resources /Pattern may be an indirect object, like any value. Reading
the reference itself as a dictionary found none and pruned nothing, so
on such a file the cell -- with the text that was under the mark --
stayed in the saved bytes, which is the leak this change is for. It is
resolved now, and what is written back is a dictionary of this page's
own, so pruning never reaches through a /Pattern dictionary another page
shares.
The controls in the test: without the first fix the surviving text's
pattern is removed (left: 1, right: 0), and without the second the
indirect file prunes nothing (left: 0, right: 1).
* M8: refuse retained unsafe tiling patterns
* M8: guard shared appearances and narrow pattern scans
* M8: update TLS dependencies for new advisories
* Redaction: the comment on prune_patterns said more than the code does
`prune_patterns` drops the `/Pattern` resource entry; the `scn` that selected
it stays in the content, so the page names a pattern its resources no longer
hold. The comment claimed the selector went too (noted in review).
ISO 32000-1 8.6.6.2 makes that operand a key of the `/Pattern` subdictionary,
so the open question is whether a reader stops reading the stream at the stale
name. `a_page_whose_pruned_pattern_is_still_selected_renders` answers it with
the renderer rather than with prose: the redacted page is saved, reopened and
rasterized, and
* it renders with no error and the same 300x300 page box,
* the text written *after* the stale selector is still painted -- which is
exactly what a reader would drop if it gave up at the bad operand,
* the redaction overlay is black over the box the pattern filled.
Control: with the drawing after the selector removed, the pixel assertion fails
("the text after the stale selector is still painted"), so it is reading that
text and not a stray pixel.
The selector is left in place rather than cut out: removing operators is a
rewrite of the content this pass does not otherwise do, and nothing surviving
paints with that colour. `pdfcraft-render` is a dev dependency of this crate
only -- layer 4 on layer 3, which the layering allows.
* WIP: pattern guard depth bound sized from the interpreter's
* Pattern tests: keep the guard's cases reaching the guard now a hit path is removed whole
* Pattern automation tests: keep the pattern in use where they test the guard, since a hit path is now removed whole
* Redaction: a form without resources keeps the page pattern it still paints
A form with no /Resources of its own paints with its caller's patterns, but
its surviving pattern paint was recorded only in the form's own output and
never reached the page. With the page's own fill under the mark removed
whole, prune_patterns then dropped /P0 from the page while the form outside
the mark still painted with it, so that fill lost its paint in the saved file.
Pass the painted names up from a form that inherits its caller's resources.
Only the painted side goes up, so this can keep a pattern, never prune one.
* Redaction: a pruned pattern does not stay named by the page tree
prune_patterns writes only the page's own /Resources, and the guard walked
only pages' effective resources. A /Pages node that still named the pruned
pattern kept its cell reachable from Root, so a full save wrote the cell,
text included, while apply returned Ok. Three shapes did it: a page with no
/Parent inheriting from the root, a /Parent that disagrees with the /Kids
tree, and a root /Resources shadowed by a nearer holder that was retired.
Patterns pruned from a page are now unlinked from page-tree holders no page
inherits from, as unlink_doomed does for XObjects, when every /Parent agrees
with the tree. Whenever a pattern was pruned (or a selected page had any),
the guard also inspects the /Resources of every /Pages node Root reaches
down /Kids and up each page's /Parent chain, so whatever stays reachable is
proven safe or the redaction is refused, leaving the document unchanged.
* Redaction: a Type 3 glyph without resources keeps the page pattern it paints
A Type 3 font with no /Resources looks the names in its glyph descriptions
up in the resources of the page or form showing it, so a glyph outside the
mark can paint with the page's pattern. Text recorded only the fill and
stroke pattern of the graphics state, so with the page's own fill under the
mark removed whole, prune_patterns dropped the pattern and the glyph lost its
paint. Showing such a font now keeps every pattern of the scope, as a form
without /Resources keeps what it paints.
* Redaction: say what text-recorded pattern use keeps
Text, inline images and XObjects record their pattern before the hit test,
so a pattern painted only by redacted text keeps its cell. The guard refuses
a cell with text or images; a vector-only cell stays in the file. The comment
said this cost only an unused resource entry. Pin the behaviour in a test.
* Redaction: the page tree is followed up every /Parent link
A full save writes every node a /Parent link reaches, but the guard followed
/Parent only from pages and stopped at the first node it had already seen,
and unlinking never followed it. A /Pages node reached only through the
/Parent of a /Kids node -- a root /Pages with a /Parent, or an intermediate
node whose /Parent leads out of the tree -- kept naming the pruned pattern,
and its cell, text included, stayed in the saved file while apply returned
Ok.
The guard now follows /Parent from every node it visits, page or /Pages, with
the same seen-set against cycles. Unlinking treats a root with a /Parent as an
inconsistent tree, like a disagreeing link, and leaves the decision to the
guard, which inspects every node those links reach and refuses an unsafe
cell.
* Redaction: a long page tree does not exhaust the pattern guard's budget
The page-tree walk counted every node, pages included, against the guard's
16,384-object budget, so redacting a pattern page of a 17,000-page document
was refused with a limit error where it had applied before. Only the holder
nodes the guard inspects count against that budget now; the walk itself is
bounded at a million nodes, as unlink_doomed bounds the same tree.
* Redaction: a Type 3 font set by an ExtGState or shown in a form keeps the page patterns
The resourceless Type 3 check covered only a font set by Tf in the scope that
paints. A Type 3 font without /Resources set through an ExtGState /Font entry
was not flagged, and a glyph shown inside a form with /Resources of its own
recorded its patterns in the form's scope, which the page never saw. In both
cases the page's own fill under the mark was removed whole, prune_patterns
dropped the pattern, and the glyph outside the mark lost its paint.
An ExtGState font is now checked the same way, and a glyph shown in any
nested form marks the page as keeping every pattern it selected. This can
only keep patterns; whatever is kept is checked by the guard.
* Redaction: a pruned pattern a full save would still write is proven safe or refused
The walks that check retained pattern cells follow the references they know
-- resource categories, the page tree, appearances -- but a full save writes
whatever the trailer reaches by any reference. A direct /Parent dictionary, a
/Kids array on a page, or a stray resource entry (/Shading naming the pattern
stream) kept a pruned cell, text included, in the saved file while apply
returned Ok.
pdfcraft_cos gains reachable_objects, which runs the same breadth-first walk
write_full uses (factored out as full_save_order, so the two cannot drift).
Before apply succeeds, every pruned pattern that walk still reaches is
inspected like a retained cell: vector-only passes, anything else refuses
with the existing pattern error. It runs only when a pattern was pruned and
costs one walk of the reachable objects.
* Redaction: a direct /Parent dictionary is part of the page tree too
A /Parent given as a dictionary rather than a reference is written inline by
a full save, but the page-tree walk followed /Parent only as a reference, and
unlinking took such a tree for consistent. A root /Pages whose direct /Parent
held /Resources naming the pruned pattern kept its cell in the saved file.
The guard now walks a direct /Parent like any node (its /Resources, /Parent
and /Kids), and unlinking counts any /Parent that is not the reference /Kids
came from as an inconsistent tree, leaving the decision to the guard.
* Redaction: page-tree walks queue each node once and borrow /Kids
On a hostile tree whose /Pages nodes share one long /Kids array, the guard's
page-tree walk and pattern unlinking pushed every /Kids entry of every node
before checking whether it had been seen, and copied the array on each
visit. Both now queue only nodes not seen yet and read /Kids in place;
unlinking also stops at the first node reached twice, since its /Parent can
agree with at most one of the nodes above it, and leaves that tree to the
guard.
* Redaction: a Type 3 font with /Resources null is resourceless too
/Resources null is the same as no /Resources, but the check counted any
entry, so such a font's glyph outside the mark lost the page pattern it
painted with. A Type 3 glyph shown by a kept annotation appearance is a known
limit, pinned as an ignored test: appearances are not interpreted for pattern
use, and under ISO 32000 the glyph resolves in the appearance's own resources.
* Redaction: a pruned pattern is recorded along its whole reference chain
A pattern name can lead to a reference-valued object whose value is the cell
(/P0 7 0 R, object 7 being 6 0 R). Pruning recorded only object 7, so the
reachability backstop checked an object nothing reached while a stray
reference kept the cell, object 6, in the saved file. Every object along the
chain is recorded now, bounded like the other walks.
* Pattern tests: pin the file identifier where two saves are compared
main now gives a redacted rewrite a new identifier from fresh entropy, so an
incremental and a full save after Apply differ in /ID alone. The test that
checks they are the same save passes fixed entropy to both.
* Redaction: replies and pop-ups removed on other pages feed the shared-appearance check
Apply checks every page for retained unsafe pattern cells when a removed
annotation's appearance is shared with one that stays on an unselected page.
Only annotations removed under a mark fed that check. Replies and pop-ups
that go with them in step 2b (removed_everywhere), often listed on another
page, did not, so a text-bearing cell in an appearance a kept annotation
shares with them escaped the all-pages check and Apply returned Ok.
Their appearance references now go into removed_appearances too, with the
same limit. Raised by FredApps' review of the rebase.
---------
Co-authored-by: skylar taylor-barrick <hi@skylar.cc>
PdfCraft
The PDF workbench; an open-source, modern PDF reader and editor, built in pure Rust.
Read, organize, combine, split and secure PDFs in a fast, native app, written in Rust from the ground up.
macOS · Windows · Linux · FreeBSD · the web
PdfCraft on getartcraft.com · ArtCraft · All Crafting Apps
The PdfCraft Showcase, a 13-page specimen PDF, open with the All tools panel and threaded comments.
Note
ArtCraft is a community of artists from all walks of life. Digital, generative, music, games — if you make things, you're one of us. Come say hi on Discord.
Highlights · Read · Find · Organize · Combine & split · Protect · Forms & layers · Everywhere · Agents · How it's built · Get started · What's next · Downloads · Crafting Apps
Community
PdfCraft is part of ArtCraft. Come say hello, get help and follow development:
- Discord: discord.gg/artcraft. This is the fastest way to get help and share feedback. The app has a Discord button in its title bar.
- Web page: getartcraft.com/apps/pdfcraft
- Source: github.com/storytold/pdfcraft
The ArtCraft name and logos in docs/brand/ are trademarks of the ArtCraft Team and are not open source. They may be used only unmodified, and only as part of PdfCraft (see docs/brand/LICENSE-brand.txt). Forks and modified versions must remove them.
Highlights
FaithfulReal-world typography: world scripts, vertical Japanese, colour emoji, gradients, soft masks and transparency. All of it renders the way the author intended. |
FearlessOrdinary saves append your changes and leave the original bytes untouched. Edits to damaged objects whose xref and header generations disagree use a full rewrite, keeping both accepted references connected to the same repaired object. Writes are atomic, undo runs deep, and nothing is lost if you close by mistake. |
YoursNo account, no telemetry, no cloud. It works offline and opens instantly. The engine, CLI and app are all open source. |
Read anything, beautifully
PdfCraft renders PDFs with care for the details that make a page feel right: kerning and ligatures, right-to-left and complex scripts, vertical CJK, colour emoji, shadings, blend modes, soft masks and optional content.
Twelve writing systems on one page, plus vertical Japanese, at 125%.
- Deep zoom stays sharp. Large pages render in tiles, so text stays crisp at any magnification.
- Built to survive bad files. Every page renders in isolation and damaged documents are repaired. Across the 983-file pdf.js test corpus the result is 0 crashes.
- Layouts for every task: continuous, single page, two-up, view rotation, full screen and a distraction-free Read mode.
- Light and dark themes, both designed to be easy on the eyes for long sessions.
 |
 |
| Two-up Read mode, ready for long reading | The dark theme, with the comments panel open |
Find it, select it, copy it
Search the whole document as you type, step through matches with ⌘G, and select text that comes out in the right reading order. That holds for columns, right-to-left runs and CJK too.
Navigate long documents
Launch with pdfcraft --two-paged file.pdf (or pdfcraft file.pdf --two-paged) to open each command-line PDF in noncontinuous two-page view. This optional launch override does not change saved default-layout preferences or PDFs restored from the previous session. An explicit --layout option takes precedence on the active document regardless of argument order; --default-layout retains its existing behavior for subsequently opened documents.
Right-click a PDF tab to close it, reopen the last closed file-backed tab, or reveal its file. Closing still asks about unsaved changes. Reopening reads the saved file from disk; it does not restore discarded edits. Reveal selects the file in Explorer or Finder. On Linux and FreeBSD it requests org.freedesktop.FileManager1.ShowItems, falling back to opening the containing directory with xdg-open when that service is unavailable. Reopen and Reveal are unavailable on the web; Reveal is also unavailable for pathless documents.
Bookmarks, page thumbnails and the document's own page labels (i, ii, 1, 2…) keep you oriented in long documents. Search bookmark titles in the Bookmarks panel to find nested entries even when their parents are collapsed. Matches keep their ancestors for context; Clear restores the unfiltered tree without changing its expansion state.
In Inspector > Pages, use Thumbnail size and the smaller/larger buttons to show more pages or inspect larger previews (50–150%). This changes only the thumbnails, keeping multi-page selection and the current page in view. The size belongs to the open document view and survives reloading its file; it is not remembered after restarting. Agents can set it with ui.set {"key":"thumbnail-zoom","value":"75"} and read active.thumbnail_zoom from ui.state.
 |
 |
| Find as you type: match 10 of 16 | Nested bookmarks with the document's own page labels |
Organize pages like cards on a table
Open Organize pages to see every page at once:
- Select pages: click, ⌘-click or ⇧-click.
- Change them: rotate, delete, insert blank pages, insert pages from another file, and move them earlier or later.
- Undo anything: ⌘Z, then save.
Organize pages with three pages selected and the page tools in the toolbar above.
|
Undo that goes the distance. Each change is one step in a history you can walk backwards and forwards. The Edit menu names the step ("Undo Rotate pages"), and undo still works after you save. Saves you can trust:
When open documents exceed the window width, scroll over the tab strip with the mouse wheel or trackpad, or use its horizontal scrollbar. Opening or switching to a document brings its tab into view. Unsaved documents carry a dot on their tab, and closing or quitting asks before anything is lost. Changes are autosaved every minute. If PdfCraft ever quits unexpectedly, it offers to recover your work the next time it opens. Encrypted documents stay encrypted on disk. |
 Split document: one page per file makes 13 files. |
Combine and split without losing a thing
Combine files merges any number of PDFs into one. Each file gets a bookmark, with its own bookmarks nested underneath.
Extract copies the pages you select into a new document. Split divides a document every n pages, or before the pages you choose.
Nothing quietly disappears along the way:
- links and named destinations are rewired to the copied pages;
- form fields stay interactive;
- layers keep their on/off defaults;
- attachments come along.
Every page of a combined document renders pixel-identical to its source.
pdfcraft-cli combine report.pdf appendix.pdf --out combined.pdf
pdfcraft-cli extract report.pdf --pages 1,3,5-8 --out highlights.pdf
pdfcraft-cli split report.pdf --every 10 --out-dir parts/
Open protected documents and respect their rules
PdfCraft implements the PDF standard security handler completely:
- every revision, from 40-bit RC4 to AES-256;
- user and owner passwords, including Unicode passwords normalised with SASLprep;
- crypt filters and attachment-only encryption.
Documents restricted by their author show a clear notice, and PdfCraft honours their permissions. Enter the owner password and the restrictions lift. Edits to encrypted documents are saved encrypted, under the same keys.
 Document Properties, Description tab |
Document Properties shows:
|
Comments, forms, layers and attachments
 |
 |
| Forms: every field with its current value, field highlighting, and checkboxes, radio buttons, lists and signatures drawn the way their author designed them. | Layers: switch optional content on and off and the page re-renders instantly. Comments appear as threaded conversations, and attachments can be opened or saved. |
Scan pages, then read the words back before trusting them
Scan & OCR ▸ Recognize text turns a scan into searchable text — the current page, a range, or a folder of files written as searchable copies — with optional cleanup before reading (auto-rotate, deskew, denoise, binarize; word boxes map back to the original scan) and a second engine: an installed Tesseract joins the built-in one, merged per your strategy. A searchable result applies as one undoable step; the Editable text output opens the OCR Verify screen instead, where each word carries the engine's confidence as a colour, suspects are one keypress away, and corrections, a user dictionary and Re-OCR of a region or a page happen before Accept writes the new document. Scan & OCR ▸ Correct recognized text reviews any recognition there before it is applied.
The OCR Verify screen: words coloured by confidence — the legend spells the thresholds out — reviewed and corrected before anything is applied.
Every tool, one keystroke away
Press ⌘K to search every tool and command, or browse the All tools catalogue. Tools that are still in development are marked with the milestone that will ship them.
 |
 |
| The ⌘K command palette | The home screen and the All tools catalogue |
Runs everywhere, stays yours
- Native on macOS, Windows, Linux and FreeBSD, and in the browser through WebAssembly, from the same Rust codebase. Windows builds come for x64, x86 and ARM64 (Windows on ARM, no emulation); every ARM64 change is tested on ARM64 hardware in CI.
- Private by design. Documents never leave your machine. There's no account, no telemetry and no cloud processing.
- Engine first. Parsing, rendering and editing live in reusable library crates. The interface is one swappable layer on top.
- Scriptable. The
pdfcraft-clitool (see Built for agents, too) covers inspecting, rendering, extracting text, editing, combining, extracting pages and splitting. Robustness sweeps run on the same engine as the app.
pdfcraft-cli info form.pdf # structure as JSON
pdfcraft-cli text paper.pdf --page 3 # reading-order text
pdfcraft-cli edit in.pdf --rotate 1,2:90 --delete 5 --title "Q3" --out out.pdf
Built for agents, too
Every engine feature is reachable without the GUI, through one table of JSON-Schema-described tools: open, inspect, render pages to PNG, extract and find text, rotate, delete, move and insert pages, edit bookmarks and page labels, add, reply to, restyle and delete comments (highlight a phrase just by naming it), list and fill in form fields, protect with passwords, set metadata, undo and redo, save, combine, extract and split. Three front doors share it:
-
pdfcraft-cli run, for one-off calls and JSON scripts:pdfcraft-cli tools # every tool and its JSON Schema pdfcraft-cli run text_find doc=1 query=invoice # key=value; values parse as JSON pdfcraft-cli run --script review.json # e.g. comment_add {"type": "highlight", "find": "total due"} pdfcraft-cli run --script steps.json --root ./work # several steps in one session pdfcraft-cli run --script steps.json --report # one JSON document: per step its number, tool, status, result or errorWith
--root, every file the script's steps read or write stays in that directory, including the PNG a step saves with"out"(the script itself is read from wherever you name it). -
An MCP server, for AI agents such as Claude. It is opt-in: PdfCraft never starts it on its own, and it opens no network port. It runs only while an agent launches
pdfcraft-cli mcp, talks over stdin/stdout, and stops when the agent disconnects. To enable it, add it to your agent's MCP configuration:{ "mcpServers": { "pdfcraft": { "command": "pdfcraft-cli", "args": ["mcp", "--root", "/path/to/your/pdfs"] } } }--compactshrinks the tool list the agent has to read:tools/listreturns about ten core tools plustool_searchandtool_call, which find and run every other tool, so the list costs far fewer tokens. Every tool still works.--rootconfines every file the agent can read or write to one directory. Builds that should not include the server at all can usecargo build -p pdfcraft-cli --no-default-features. -
The Rust API (
pdfcraft_automation::Automation::call), for embedding.
Edits stay in memory, undoable, until doc_save. Saving to the same file appends an incremental update, so the original bytes are preserved, and the write is atomic. Unsaved changes are never discarded silently.
Driving the app itself
Start the desktop app with pdfcraft --control ~/.pdfcraft-control.json and an agent can see and operate the real interface: the widget tree with labels and positions (from the accessibility tree), clicks, typing, keys, commands, view options and screenshots. This is also off by default. It listens only on loopback, and every connection must present the random token written to that file, which only you can read.
Keep the control file in a folder only you can write, not a shared one such as /tmp: another user could create the file there first and receive your commands. pdfcraft-cli ui refuses a control file that is a symbolic link, and on macOS, Linux and FreeBSD one that another user owns or can read or write. The app doesn't start if it can't write the file.
pdfcraft-cli ui --control ~/.pdfcraft-control.json inspect query=rotate # find widgets
pdfcraft-cli ui --control ~/.pdfcraft-control.json click label="Organize pages"
pdfcraft-cli ui --control ~/.pdfcraft-control.json key key=K modifiers='["command"]'
pdfcraft-cli ui --control ~/.pdfcraft-control.json command id=comment.square # pick a tool, then draw:
pdfcraft-cli ui --control ~/.pdfcraft-control.json drag from='[400,300]' to='[600,420]'
pdfcraft-cli ui --control ~/.pdfcraft-control.json screenshot --out window.png
pdfcraft-cli ui --control ~/.pdfcraft-control.json resize width=1200 height=800
pdfcraft-cli ui --control ~/.pdfcraft-control.json focus label="Read"
pdfcraft-cli ui --control ~/.pdfcraft-control.json inspect focused=true
pdfcraft-cli ui --control ~/.pdfcraft-control.json quit
ui.panel opens, closes or sizes a side panel: {"panel":"tools"|"side","open":true|false,"width":320}.
tools is the Tools panel and side the panel the rail opens (reopening it shows the one open last).
width is clamped to the panel's limits (Tools 240–520, side panel 260–520 points). ui.dock.reset
resets the side panels: Tools open on the left, default widths. The control channel accepts these
methods directly; ui.command also accepts {"id":"ui.panel","params":{...}}. Saved preferences keep
the Tools side, the open panels and their widths. Invalid requests return an error without changing
the document or the panels.
resize requests a native inner-window size in logical points (each dimension must be between 320 and 8192); the window manager may constrain it. state reports the observed window.width, window.height and window.pixels_per_point. focus accepts exactly one widget id or unique enabled, focusable label; subsequent key requests traverse or activate the actual widgets. inspect includes focusability and accepts a focused filter. quit takes no parameters: clean documents exit normally, while unsaved edits or typing open the existing Save/Don't save/Cancel prompt and return quitting: false, needs_confirmation: true. It never silently discards work. Window resizing and application quit are native-only.
How it's built
PdfCraft is a Cargo workspace of focused crates, layered so the core never depends on the UI:
| Crate | What it does |
|---|---|
pdfcraft-filters |
Every PDF stream filter (Flate, LZW, ASCII85, RunLength, predictors), encode and decode, property-tested |
pdfcraft-crypt |
The standard security handler: RC4, AES-128/256, revisions 2–6, permissions |
pdfcraft-cos |
The PDF object layer: tolerant parsing, repair, copy-on-write edits, incremental and full writing |
pdfcraft-organize |
Page operations, combine / extract / split, bookmarks, page labels, document information |
pdfcraft-fonts |
Font metrics and encodings for generated appearances |
pdfcraft-annot |
Comments: builders and appearance streams for notes, text markup, shapes, ink and text boxes; replies, status, edits |
pdfcraft-forms |
Interactive forms: the field model, filling with regenerated appearances, Clear form |
pdfcraft-render |
Rendering, inspection and text extraction with reading order |
pdfcraft-engine |
The façade every frontend uses: sessions, edits, undo, saving, the tool catalogue |
pdfcraft-automation |
Agent control: the headless tool table, pdfcraft-cli run, and the opt-in MCP server |
pdfcraft-ui-egui |
The desktop and web interface |
Quality gates. Every change passes the same automated checks:
- formatting, and Clippy with warnings as errors;
- 200+ unit, property and UI tests;
- crate-layering rules and a WebAssembly build check;
- an asset-licence audit.
On top of those, two corpus sweeps run over real-world files:
- Opening and rendering: of the 983 pdf.js test files, 963 open and render cleanly, with 0 crashes.
- Open, edit and save round trips: 958 succeed.
The output is verified against independent implementations: hayro and qpdf on every CI run, and
poppler over the corpus on demand (cargo xtask text-oracle).
PdfCraft is a clean-room implementation. Its behaviour comes from the ISO 32000 specification and black-box observation, never from anyone else's code. Every icon, font and image is openly licensed and listed in ATTRIBUTION.md.
Get started
Building needs Rust 1.95 or later.
git clone https://github.com/storytold/pdfcraft
cd pdfcraft
cargo xtask models # fetch the OCR models Scan & OCR needs (release builds include them)
cargo run --release -p pdfcraft -- some.pdf # desktop app
cargo xtask demo-pdf # build the showcase PDF used in these screenshots
cargo xtask screenshots # regenerate every screenshot in this README
The interface language is chosen in Menu → Edit → Preferences… (Command-comma on macOS, Ctrl-comma elsewhere, also with no document open; Auto follows the system language; see docs/localization.md) and saved. Japanese covers commands, dialogs, panels and keyboard shortcuts. Command search accepts the translated label, the English label and the stable command id; filenames, PDF contents, author names, custom action names and error details from the engine or the operating system keep their own text.
Japanese fonts come from craft-fonts, an optional build input that every release includes. To build with them (Japanese interface text, and Japanese text in edited PDFs):
git clone https://github.com/storytold/craft-fonts ../craft-fonts
CRAFT_FONTS_DIR=../craft-fonts cargo run --release -p pdfcraft -- some.pdf
Each GitHub release has ready-made builds for macOS,
Windows, Linux (AppImage, Flatpak, .deb, .rpm and a tarball), FreeBSD and the web; see
Downloads. On Gentoo, the community ::snakebyte
overlay packages the Linux release as
app-text/pdfcraft-bin (not maintained by the PdfCraft team):
eselect repository add snakebyte git https://github.com/switch87/snakebyte-overlay.git
emaint sync -r snakebyte
echo 'app-text/pdfcraft-bin ~amd64' >> /etc/portage/package.accept_keywords/pdfcraft
emerge --ask app-text/pdfcraft-bin
Logs, environment variables and other development notes are in docs/development.md.
What's next
PdfCraft is young and moving fast. The aim is a workbench where you can view, organize, annotate, fill, sign and edit PDFs, for professional and everyday workflows.
Where it stands (October 2026), honestly: PdfCraft is alpha. Most essential offline PDF features exist in some form (57% of the features tracked in docs/target-app-parity.md, 94% of core essentials). For everyday work (viewing, commenting, filling and signing forms, organizing pages) readiness is about 55%; across all professional workflows, about 49%; for someone who only needs the essentials, about 66%. Every everyday workflow can be completed, but converting and sharing is weak: no office-document-to-PDF, and .docx export that loses layout.
- Good today: viewing and search; organizing, combining and splitting; most kinds of comment; filling and authoring forms (with sandboxed JavaScript); passwords, redaction and sanitizing; basic digital signatures; printing; the Accessibility Checker; agent control through the CLI and MCP.
- Still borrowed: pages are drawn by the
hayrocrate while our own renderer is built. - Thin or missing: reliable editing of existing text (especially CJK and right-to-left), OCR beyond Latin script, office document import/export, signature tokens and online long-term validation, Preflight and PDF/X/UA, printing from the web build, physical printer fidelity, and full XFA forms.
- Hardening: fuzzing still turns up crashes and hangs on hostile files; each one is fixed with a regression test. Quality has not yet been benchmarked side by side.
Next, in order: office-document-to-PDF and a .docx export that keeps layout, the reported bugs and the Chinese interface font, a fidelity harness against a reference renderer, editing existing content, then professional workflows (OCR, office formats, Preflight, signatures, accessibility tagging) and 1.0 polish.
The summary is in ROADMAP.md; the full assessment by dimension and area is in docs/target-app-parity.md, the ranked gaps in docs/gaps.md, and the milestones in docs/roadmap.md.
Downloads
New to PdfCraft? Download it from the PdfCraft page on getartcraft.com. That's the easiest way to install it.
Want a specific build or format? On GitHub, the latest release has every build listed below, and all releases has earlier versions and their notes. <ver> in the file names is the version number, and SHA256SUMS.txt lists a checksum for every file.
Windows
| Build | Installer | Portable |
|---|---|---|
| x64 (64-bit Intel/AMD) | pdfcraft-<ver>-windows-x64.msi |
pdfcraft-<ver>-windows-x64-portable.zip |
| arm64 (Snapdragon and other ARM PCs) | pdfcraft-<ver>-windows-arm64.msi |
pdfcraft-<ver>-windows-arm64-portable.zip |
| x86 (32-bit) | pdfcraft-<ver>-windows-x86.msi |
pdfcraft-<ver>-windows-x86-portable.zip |
Installers and executables are code-signed.
The portable zip runs from any folder, a USB stick included. Its portable.txt keeps the settings,
logs and crash recovery in a PdfCraftData folder next to pdfcraft.exe, so nothing is written to
%APPDATA%; delete that file to use the normal per-user folders.
The MSI installs for your account only by default, without administrator privileges. Choose
"Everyone on this computer" on its first page, or pass ALLUSERS=1 from an elevated terminal, to install
for all users. It adds "Edit with PdfCraft"
to the right-click menu of PDF files and "Create PDF with PdfCraft…" to the right-click menu of
images (.png .jpg .jpeg .tif .tiff .gif .bmp .jp2 .j2k .jpx) in File Explorer (on Windows 11, under
"Show more options"), without changing which app opens them by default. For unattended deployment
without a desktop shortcut (add ALLUSERS=1, from an elevated terminal, for an all-users install):
msiexec /i "pdfcraft-<ver>-windows-x64.msi" /qn /norestart INSTALLDESKTOPSHORTCUT=0
| Property | =0 leaves out |
|---|---|
INSTALLDESKTOPSHORTCUT |
the desktop shortcut |
INSTALLPDFCONTEXTMENU |
"Edit with PdfCraft" on PDF files |
INSTALLIMAGECONTEXTMENU |
"Create PDF with PdfCraft…" on images |
All three are on for a first install. An upgrade keeps what the installed version has: a shortcut
or menu entry that is there stays, and one that is missing (left out at install, or a desktop
shortcut someone deleted) stays missing, so you don't need to pass them again. A value on the
command line always wins: =1 puts one back and =0 removes it. Upgrading from a release that
didn't have a menu yet (0.6.0 and earlier for the PDF menu, 0.2.1 and earlier for the image menu)
adds it, as a first install would. Use the MSI for your architecture. Per-user installation
overrides are not supported.
Pin the checksum, not just the version. Release candidates of a version share its MSI version
(MSI versions are numbers only, so 1.2.3-rc.1 and 1.2.3 are both 1.2.3), and the installer lets an
MSI of the same version replace the installed one without asking. Two different 0.7.1 MSIs can't
be told apart by version, so if your deployment tool checks the file, pin its SHA-256 from
SHA256SUMS.txt (Get-FileHash <file> -Algorithm SHA256).
Signing identities. The Windows MSIs and both executables are signed through Azure Trusted
Signing with a certificate issued to Learning Machines Inc (Atlanta, Georgia, US). The macOS app
and command-line tool are signed with the Developer ID Learning Machines LLC (DJ6XS33FX8) and
notarized. The MSI's manufacturer, shown as the publisher in Installed apps, is
Learning Machines LLC.
macOS
| Build | File | Notes |
|---|---|---|
| App, universal (Apple silicon + Intel) | pdfcraft-<ver>-macos-universal.dmg |
Signed and notarized |
| Command-line tool, universal | pdfcraft-cli-<ver>-macos-universal.zip |
Signed and notarized |
Linux
| Format | x86_64 | aarch64 (ARM64) | Notes |
|---|---|---|---|
| AppImage | pdfcraft-<ver>-linux-x86_64.AppImage |
pdfcraft-<ver>-linux-aarch64.AppImage |
Runs anywhere; updates itself with AppImageUpdate (.zsync files) |
| Flatpak | pdfcraft-<ver>-linux-x86_64.flatpak |
pdfcraft-<ver>-linux-aarch64.flatpak |
Sandboxed; flatpak install --user <file> |
| Debian/Ubuntu | pdfcraft-<ver>-linux-x86_64.deb |
pdfcraft-<ver>-linux-aarch64.deb |
|
| Fedora/RHEL/openSUSE | pdfcraft-<ver>-linux-x86_64.rpm |
pdfcraft-<ver>-linux-aarch64.rpm |
|
| Tarball | pdfcraft-<ver>-linux-x86_64.tar.gz |
pdfcraft-<ver>-linux-aarch64.tar.gz |
Unpack anywhere |
| Command-line tool | pdfcraft-cli-<ver>-linux-x86_64.tar.gz |
pdfcraft-cli-<ver>-linux-aarch64.tar.gz |
pdfcraft-cli alone (and its opt-in MCP server), for servers, CI and agents |
RISC-V (riscv64) builds come as tarballs only: pdfcraft-<ver>-linux-riscv64.tar.gz and pdfcraft-cli-<ver>-linux-riscv64.tar.gz. They are cross-compiled and need glibc 2.39 or newer (Ubuntu 24.04+, Debian 13+).
Every other Linux build needs glibc 2.35 or newer (Ubuntu 22.04+, Debian 12+, Fedora 36+, RHEL 10).
FreeBSD
| Build | File |
|---|---|
| x86_64 | pdfcraft-<ver>-freebsd-x86_64.tar.gz |
Web (WebAssembly)
| Build | File | Notes |
|---|---|---|
| Static site | pdfcraft-web-<ver>.zip |
Runs in a modern browser; host it on any static server |
The Crafting Apps
PdfCraft is one of the Crafting Apps: free, open-source creative tools from the ArtCraft team, each written from scratch in Rust and each able to stand on its own.
| App | What it's for | Code | Learn more | |
|---|---|---|---|---|
 |
PhotoCraft | Image editing: layers, masks, type and real PSD files | GitHub | Website |
 |
VectorCraft | Vector illustration | GitHub | Website |
 |
FilmCraft | Video editing, color and sound | GitHub | Website |
 |
LightCraft | Photo library and raw development | GitHub | Website |
 |
PdfCraft | Reading, organizing and protecting PDFs | GitHub | Website |
 |
EffectCraft | Motion graphics and visual effects | GitHub | Website |
 |
DesignCraft | Page layout and publishing | GitHub | Website |
 |
FigCraft | Interface design and prototyping | GitHub | Website |
 |
WordCraft | Word processing and documents | GitHub | Website |
 |
SoundCraft | Audio recording and editing | GitHub | Website |
 |
DeckCraft | Presentations and slide decks | GitHub | Website |
 |
CADCraft | Computer-aided design | GitHub | Website |
 |
GridCraft | Spreadsheets and data | GitHub | Website |
 |
TextureCraft | 3D texture painting | GitHub | Website |
 |
Craft Anything | See how any software works, then build your own | GitHub | Website |
 |
SolidCraft | Parametric 3D CAD by Tangency Labs (community app) | GitHub |
And ArtCraft itself, our AI image and video studio for artists who want real control.
Come make things with us
Our Discord is where artists of every kind hang out: people who paint, shoot, draw, cut film, set type, and people still figuring out what they like to make. Share what you're working on, ask for help, tell us what's broken, or tell us what you wish these tools could do. Whatever your medium and however long you've been at it, you're welcome here.
discord.gg/artcraft · getartcraft.com · The Crafting Apps · PdfCraft
License and credits
PdfCraft is dual-licensed under MIT or Apache-2.0, at your option. Copyright (c) 2026 ArtCraft Team and the PdfCraft contributors. Required notices are in NOTICE.
Bundled fonts, icons, images and other assets keep their own open licenses; each one is listed with its author, source and license in ATTRIBUTION.md. Release builds also embed the Japanese fonts of craft-fonts (SIL Open Font License 1.1).
The ArtCraft name, wordmark and logos in docs/brand/ are trademarks of the
ArtCraft Team and are not covered by this license. They may be used only unmodified, and only as
part of this repository and PdfCraft, under docs/brand/LICENSE-brand.txt.
Forks and modified versions must remove them.
Made by the ArtCraft team and community.
The Tools panel sits on the left, or on the right with Preferences ▸ Tools panel side. The rail stays at the right edge and opens one side panel beside it. Drag a panel's inner edge to resize it; widths are remembered. F4 shows or hides the side panel and Shift+F4 the Tools panel (also in the View menu); View ▸ Reset side panels restores the default arrangement.