Commit Graph
472 Commits
Author SHA1 Message Date
561377eb1f Keep document view state consistent when closing tabs and reverting (#439)
Preserve the selected document when an earlier inactive tab closes. Clear the reverted document's form drafts and queued edit only after a successful Revert.

Co-authored-by: sanyamsingh001 <[email protected]>
Co-authored-by: Codex <[email protected]>
2026-10-09 09:15:06 -04:00
pauliusiv123-rgb 3c771e0395 Issue #425: long file names and paths on Home end in "…" before the row's details (#443) 2026-10-09 09:15:00 -04:00
MarekSpodBiedry 5c5f4d8b49 Phone photos follow EXIF orientation; image signatures stay upright on rotated pages (#434) (#485)
* Stamps and added images follow a JPEG's EXIF orientation (part of #434)

Phones store a portrait photo as landscape pixels plus an EXIF
Orientation tag. A JPEG went into the PDF as it was (DCTDecode), and PDF
image XObjects have no such tag, so a photo used as a custom stamp, an
added or replaced image, a watermark or background, or a button image
showed up turned 90 degrees.

Before these images are embedded, a JPEG whose Orientation is not 1 is
decoded, turned the way the tag says and re-encoded (quality 92). Its
JFIF resolution is kept, swapped for quarter turns, so the natural size
on the page stays right. Other images, JPEGs without the tag, JPEGs that
fail to decode and photos over 64 megapixels are embedded unchanged, as
before. Fill & Sign image signatures already applied the tag.

* Image signatures stay upright and anchored on rotated pages (part of #434)

On a page with /Rotate 90, 180 or 270 an image signature turned with the
page, because its picture was drawn along user-space axes while the click
or the "at" argument is a displayed point. It was also anchored at the
wrong point: its left edge and vertical centre were taken in user space,
so on a 90 degree page the image centre ended up elsewhere.

The signature's appearance now carries the counter-rotation as its form
/Matrix, which viewers fit to /Rect, so the picture reads upright as
displayed. The page's rotation is kept in /PCPictureRotate, so restyling
regenerates the same matrix and moving and resizing keep it. The box of the
signature runs along the displayed axes, so its left edge and vertical
centre are where they were asked for. The page view matrix in
pdfcraft-model is split out as view_matrix_for.

The Fill & Sign preview and the live move/resize preview draw the picture
the way the appearance does, and the resize handles keep the image's
proportions as displayed. comment_image_preview reports image_rotation,
how far the image is shown turned (0 for one placed upright).

Custom image stamps are left to #473.

* Use is_multiple_of for the quarter-turn checks (clippy) (#434)

* Probe the pointer preview away from egui_kittest's drawn cursor (#434)

The kittest render paints a mouse cursor (a 16 px triangle with a black outline) at the
hover point, so the 2 pt probe beside the pointer landed on its outline when zoom and view
rotation made 2 pt only a pixel or two. Put the stroke's block at the picture's right end and
probe there and at its far margin instead.
2026-10-09 09:14:55 -04:00
Chen TaoandClaude Opus 5.5 5f570eab01 M2.6: non-embedded Mincho fonts draw half-width katakana (#484)
Since #368, a non-embedded Adobe-Japan1 font with a Mincho name
(HeiseiMin-W3, MS-Mincho, ...) is drawn in document_japanese_font(),
i.e. Shippori Mincho. Shippori Mincho has none of the 63 half-width
katakana (U+FF61-U+FF9F), which are common in Japanese documents.
hayro maps the CID through Adobe-Japan1-UCS2 to Unicode, finds no
glyph in the face's cmap, and falls back to drawing the CID as a glyph
index: half-width katakana came out as unrelated glyphs (ligatures
such as fi and fl).

The Mincho substitute is now BIZ UDMincho Regular, which covers
half-width katakana (and was designed as a metric-compatible
replacement for MS Mincho), falling back to document_japanese_font()
when it isn't built in. The face used for Japanese text written into
PDFs is unchanged. Without craft-fonts nothing changes.

Tests: raster::tests::mincho_substitute_covers_half_width_katakana
(with CRAFT_FONTS_DIR: the Mincho substitute's cmap maps U+FF61-U+FF9F
and 日本; it lacked all 63 half-width katakana before; skips without
craft-fonts). skrifa 0.44 is a dev-dependency of pdfcraft-render for
it, the version pdfcraft-fonts already uses. The parity entry
view.render-cid-fonts cites the test.

Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-09 09:14:46 -04:00
MarekSpodBiedry 271139bd3b Comments: a new highlight opens its note for typing (#475) (#481)
Adding a highlight selected its card in the Comments panel but left the
note closed; the text field only appeared after double-clicking the card.
Acrobat opens the note for typing as soon as the highlight is made.

apply_edit now opens the inline editor for a new highlight (text drag,
selection then tool, area highlight all pass through it), unless a note
typed into another card is still unsaved, so that text is never dropped.
2026-10-09 09:14:40 -04:00
Erige005 bc1d67cb61 Export to Word: detect tables of at most 63 columns, Word's limit (#479) (#483) 2026-10-09 09:14:34 -04:00
Hal GoffandClaude Opus 5.5 7d9cc53472 Issue #225: a closed Comments panel stays closed when picking comment tools (#501)
Picking any comment tool opened the Comments panel whenever no right panel
was open, so closing it was undone by the next tool switch. Now closing
Comments (its close button or the rail icon) is remembered, across restarts,
and comment tools leave it closed until the user opens it again (rail, View
menu, Comments ▸ list, or a Reply action). Switching to or closing another
panel doesn't count. Opening a document with comments still shows them, as
Acrobat does.


Claude-Session: https://claude.ai/code/session_01VNJqS2dEQawHJn1qTRJiKp

Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-09 09:14:27 -04:00
966bd0ffce tests: pin the interface language so the suite passes outside English (#502)
The ui-egui integration tests drive the shell by its English labels, and
`i18n::system_lang` returns `Lang::EN` under `cfg!(test)` so they can. That
only covers the unit tests: an integration test links the library as it
ships, where `cfg!(test)` is off, so `PdfCraftApp::new()` leaves `language`
on `auto` and the shell is drawn in the system language. On a Spanish
Windows eleven of the test binaries fail; a French, Russian, Chinese,
Japanese, Portuguese, Czech or Telugu machine does the same. CI never sees
it because its locale is English.

`tests/theme.rs` and `tests/create.rs` already pin the option; the other
119 harnesses now do too, and the comment in `system_lang` says why, so a
test copied from an existing one keeps the line.

Also `i18n::tests::windows_display_language_query_returns_a_locale_tag`
treated the return of `windows_ui_language()` as a single tag. It is the
preferred-language list, one tag per line, as `first_supported` reads it,
so on a Windows with two or more display languages the assertion tripped
over the newline. It now checks the shape of every line.

Co-authored-by: Fernando Areán <[email protected]>
Co-authored-by: Claude Opus 5 <[email protected]>
2026-10-09 09:14:19 -04:00
Hal GoffandClaude Opus 5.5 e93a6f255f Never crash: CMap parsing can't panic, overflow or run away; tokens need no spaces (#495)
The font-metrics CMap parser (ToUnicode and embedded CID CMaps) split the
stream on whitespace and sliced hex tokens as UTF-8 text:

- a non-ASCII byte inside `<...>` sliced a character in half and panicked
- `bfrange` arrays and `/Differences` incremented code counters past
  u32::MAX, and CID lookup added `c + (code - lo)` unchecked
- 4 KB of overlapping `bfrange`s could ask for millions of map entries
- legal CMaps with no space between tokens (`<0001><0070>`) mapped
  nothing, so their text was not found for editing

A byte-level lexer now reads hex strings (whitespace inside allowed),
brackets, names, literal strings and comments. Counters use checked or
saturating arithmetic, array entries stop at the range's `hi`, and a CMap
adds at most 1 Mi ToUnicode entries and 64 Ki codespace/CID ranges. A bad
array entry still stands for its code, as before.


Claude-Session: https://claude.ai/code/session_01VNJqS2dEQawHJn1qTRJiKp

Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-09 09:14:13 -04:00
MarekSpodBiedry ff496918a1 M7: pick a Japanese fallback face that has every glyph of the edited text (#384) (#472)
Replacing text in a serif line (Times New Roman, say) with Cyrillic failed
with "Japanese fallback font has no glyph for U+0444". The Type 3 fallback
took only the style's first face, Shippori Mincho, which has no Cyrillic,
although BIZ UDMincho and BIZ UDPGothic ship alongside it.

`document_japanese_fonts_for_style` lists every Japanese face in the
existing order of preference, and `type3_font` uses the first one that has
a glyph for every character. If none has them all, the preferred face still
names the missing character, as before.
2026-10-09 09:14:04 -04:00
StreetblockandOpenAI Codex 5c354023ab M2: handle Unicode dates and preserve inspection fallback pages (#469)
Read the date prefix at a checked UTF-8 boundary and leave malformed dates
unchanged. Commit auxiliary metadata only after successful inspection so
an escaped inspector panic cannot discard the renderer's page geometry.

Add synthetic date-boundary, UTF16BE annotation and independent failure
regressions.

Co-authored-by: OpenAI Codex <[email protected]>
2026-10-09 09:13:56 -04:00
StreetblockandOpenAI Codex a9a7eea2cc M1: enforce decoded limits on unfiltered COS streams (#477)
Check the effective output limit before cloning a stream with an empty
decoder chain. Share the raw guard between tolerant and strict decoding,
including empty filter arrays and already-applied Crypt filters.

Add small regressions for exceeded, exact and zero-byte limits and keep
filtered decoding behavior unchanged.

Co-authored-by: OpenAI Codex <[email protected]>
2026-10-09 09:13:46 -04:00
4e79bbdbdf CI: no macOS on PRs or main; macOS is built and tested by releases (#512)
The org has 5 macOS slots in total (GitHub Team), shared by every repo's CI and
release builds, and PR CI kept them full, so release builds queued behind it.
macOS now runs only in release.yml; a release that fails on macOS is fixed and
rebuilt.

Co-authored-by: Brandon Thomas <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-09 08:51:23 -04:00
Xus BadiaandClaude Opus 5.5 084f7636ea macOS DMG: branded window background and icon layout
The DMG opened as a plain Finder window. It now shows the app icon's figure on
the PdfCraft colour, with PdfCraft.app and the Applications link side by side.
Same approach as PhotoCraft's and VectorCraft's.

- packaging/macos/dmg/: background.svg (source; text outlined, no paper grain,
  the figure an <image> of assets/app-icon), background.tiff (1x + 2x HiDPI,
  16-colour palette, Deflate, sRGB; ~95 KB) and dmg-layout.DS_Store (Finder
  view settings: window, icon size 128, positions, background).
- generate.py writes the TIFF and the layout on any OS, byte-for-byte
  reproducible, with nothing from the machine that ran it.
- package.sh copies them into the staging folder; the image is still built with
  hdiutil makehybrid. Nothing extra runs in the signing job.
- The volume name drops the version: the layout finds the background through
  an alias that includes the volume name. The DMG file name keeps the version.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-09 07:38:19 +02:00
cyfung1031andClaude Opus 5.5 a6bc63a497 M3: render pool renders each request once when the caller re-sends it (#400)
The canvas rebuilds its render queue from every page, tile and text layer it
is still missing, and calls `set_queue` whenever that list changes, which is
whenever any answer arrives. Requests a worker had already popped were still
missing, so they went back into the queue and an idle worker rendered them a
second time. With one worker every other page was rendered twice; with seven
workers about half of all renders were duplicates. A slow page could also take
every idle worker in turn until the watchdog fired.

The pool now remembers the requests its workers have taken until `try_recv`
hands out their answer. A queued request equal to one of them is skipped, and
an answer removes queued copies of its request. Equal requests to one pool
always produce the same answer (its bytes and settings never change), so
nothing the caller sees changes except that answers arrive sooner.

Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 22:46:32 -04:00
3146e8767e M7: preserve Japanese Gothic fallback family and weight (#394)
* M7: select real Japanese fallback faces by family and weight

Refs #184. Keep Type 3 font-name reporting separate in #387; missing weights and the small web font input remain explicit limitations.

Assisted-by: OpenAI GPT-6.1 (gpt-6.1-sol)

* Test the Japanese fallback name for a sans source: the Gothic face since #394 matches the source style

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Brandon Thomas <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 21:48:02 -04:00
0afe0b7094 Keyboard shortcut to enter page number to jump to (#393)
* added view.read_mode command

* added view.focus_page_input

* Go to page…: Ctrl+Shift+N / ⇧⌘N (Acrobat's), no indexing, rustfmt, catalog entries

Shift+Y alone (the first proposal) would have typed a capital Y in text fields
on Windows and Linux.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Brandon Thomas <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 21:37:22 -04:00
9c63f3e8f2 fix(cli): validate page positions and preserve command results (M13) (#391)
Reject invalid page positions before input I/O and keep diagnostic stderr
failures from overriding rendering, text errors or MCP startup. Preserve
real file and protocol output failures and upstream compact MCP behavior.

Co-authored-by: sanyamsingh001 <[email protected]>
Co-authored-by: Codex <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 21:37:09 -04:00
d4d2e83273 FDF: replies and review status keep their parent comment (fixes #333) (#388)
FDF export dropped /IRT, so a note's replies and its review-status reply
imported as unrelated comments. Each comment is now an indirect object of
the FDF (with a cross-reference table), and a reply's /IRT points at its
parent's object there, as ISO 32000-2 §12.7.8.3.1 allows. Import maps the
FDF objects to the placed comments and links replies in a second pass,
falling back to a parent of the same /NM already in the document.

FDFs with direct comment dictionaries still import. Self-references,
missing parents and cycles are ignored without panicking.

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 21:03:30 -04:00
midasdfandBrandon Thomas 438a269bac M7: report Japanese Type 3 fallback font names (#387)
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 21:03:16 -04:00
dc356f0dfc Linux: accept file:// URI args so desktop launchers recognise pdfcraft as PDF default (#382)
* Linux: accept file:// URI args so desktop launchers recognise pdfcraft as PDF default

GNOME Files (and other freedesktop-spec launchers) only register an app as the
default handler for a mimetype if its .desktop Exec accepts URIs (%u/%U), not
just paths (%F). pdfcraft's entry used %F, so even after `xdg-mime default
ai.storyteller.pdfcraft.desktop application/pdf`, double-clicking a PDF in
Files silently fell back to another installed viewer.

Switch Exec to %u and decode file:// args back to plain paths in main.rs
before they reach the rest of the app, which only ever opens paths. Other
schemes and plain CLI paths pass through unchanged.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

* path_from_arg: file://localhost, foreign hosts left alone, Windows drive paths, no indexing; Exec %U (several files)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Dmitriy Bunakalya <[email protected]>
Co-authored-by: Claude Sonnet 5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 20:04:27 -04:00
pauliusiv123-rgbandBrandon Thomas 85dcb9dece Issue #295: three clicks select the line, four clicks the page (#366)
* Text: find the word and the line around a glyph

PageText gets word_at(i) and line_at(i). Each returns the first and
last glyph of the word or the line around glyph i, or None when i is
past the end of the page's text. A word stops at a word gap, a blank
glyph or a line end. A line is the run of glyphs with the same line
number.

The canvas's double-click used its own loop for this, which indexed the
glyph, line and gap arrays directly. It now calls word_at, which reads
them with get(). Double-clicking selects the same words as before.

Test: render words_and_lines_around_a_glyph, on two lines with a blank
glyph, a word gap and a line break.

* Issue #295: three clicks select the line, four clicks the page

With the Select tool, quick clicks on text widen the selection like
Acrobat: two clicks select a word (as before), three the line, four or
more all the text on the page. A third click used to clear the
selection.

egui counts only up to triple clicks and reports a fourth quick click
as another triple, so the view keeps its own count of the current run.
A single click resets it and a pause ends it.

With the markup tools (Highlight and the like) and Redact, a
double-click already turns the word into a mark at once. They stop at
the word, so more clicks don't stack line or page marks.

Tests: ui-egui quick_clicks_select_a_word_then_the_line_then_the_page
and quick_clicks_with_the_highlighter_mark_only_the_word.

parity: view.text-select cites the tests. The notes say what is
missing: paragraph selection, and Ctrl/⌘+A across the whole document
(it selects the current page).

* Clippy: as_chunks in the signature preview test (follow-up to #355)

Clippy 1.99 rejects chunks_exact with a constant chunk size
(chunks_exact_to_as_chunks), so `cargo clippy --workspace --all-targets
-- -D warnings` fails on main since #355. Use as_chunks, as #360 did
for the test above it.

---------

Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 20:04:10 -04:00
31f3631868 Home: pin folders and list their newest PDFs (#383)
* Home: pin folders and list their newest PDFs

File > Pin folder to Home... (or "Pin a folder..." on Home) pins up to 8
folders. Each lists its newest PDFs with how long ago and size, opens one
with a click, and can be unpinned. Folders are read on a worker thread and
listed again every few seconds while Home shows, so new scans appear by
themselves; an unreadable folder (moved, offline synced drive) stays pinned
and says so. A folder is described by where it is ("iCloud Drive",
"OneDrive - Contoso", "Documents > Work") instead of its full path.

Cloud drives work through their local synced folder; nothing goes through a
provider API. Settings keep absolute paths only, deduplicated and capped.

Tests: crates/ui-egui/tests/folders.rs (8) and folders_ui unit tests (4).
Command label translated in every catalog; Home strings in fr, es, ja,
zh-hans and zh-hant; catalog hashes updated in ATTRIBUTION.toml.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Add my contributor name (amitabhthakur)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Home pinned folders: Russian strings; regenerate ATTRIBUTION.md

The Russian catalog (#375) landed while this branch was open: its coverage
tests need the new command label and Home strings. ATTRIBUTION.md is
regenerated (cargo xtask assets --write), which also adds the ru.tsv row
that #375 left out.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 19:59:24 -04:00
07b95409bf Comments without an appearance stream are drawn (display only, never saved) (#371)
* M5: comments without an appearance stream are drawn (display only, never saved)

#260 (page 7): a FreeText box with /DA and an orange /C background, a
Text note and an Ink stroke, all without /AP, were not drawn; Acrobat,
MuPDF, PDFium and Poppler draw them. The renderer only draws /AP (plus
the Highlight fallback of #274), and pdfcraft-annot, which already
draws all of these for PdfCraft's own comments, can't be used from the
renderer (both are L3).

pdfcraft_annot::with_missing_appearances returns a copy of the document
in which every annotation without /AP /N that appearance::build can
draw (FreeText, Ink, Text, FileAttachment, stamps, shapes, lines,
markup, …) has the appearance build draws from its dictionary; links,
form fields and pop-ups are left alone, as is anything build declines.
The engine keeps that copy, written as an in-memory incremental update,
in a new Document::display: the page view's render pool, page_render
and page images (export_source) read it. Document::bytes, what Save,
signatures and the inspector use, is unchanged. display is rebuilt
wherever the renderer was (open, refresh, scoped refresh) and is bytes
itself when nothing is missing or the document can't be edited.

Tests: annot tests::comments_without_appearances_get_one_for_display_only
(FreeText, Ink and Text get /AP /N in the copy, an existing /AP is kept,
Link, Widget and an unknown subtype aren't touched, the original is
untouched, none means no copy) and engine
tests::comments_without_appearances_are_drawn_but_not_saved (the page
view draws the FreeText background and the Ink stroke, before and after
an edit; the working bytes stay the opened file; Save writes no /AP).
On main the page view shows white where the FreeText box is. Parity:
view.render-annotation-appearances cites the test and notes what's left
(Link borders without /AP, printing).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Test the Ink stroke on its apex row: Ink is now a curve through its points (#374)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 19:43:58 -04:00
3b8a274f52 M2.6: non-embedded Japanese CID fonts draw in a craft-fonts face (#368)
#260 (page 2): text in a Japanese CID font that the PDF doesn't embed
(HeiseiMin-W3 with UniJIS-UCS2-H, Adobe-Japan1) drew nothing, while
MuPDF, Poppler, PDFium and Acrobat draw it in a Mincho face. hayro asks
its font resolver for a substitute with the CID collection in the
query, but the renderer never installed one, so hayro's default
answered with a Latin standard-14 font that has no Japanese glyphs.
Release builds have embedded Japanese faces from craft-fonts all along;
the renderer just didn't use them.

RenderConfig::settings now installs a resolver: for an Adobe-Japan1
fallback query it returns a craft-fonts face (Shippori Mincho for
Mincho names, BIZ UDPGothic Regular or Bold for Gothic names, the
descriptor's serif flag otherwise); every other query keeps hayro's
default. hayro already maps such fonts through the Adobe-Japan1-UCS2
CMap to Unicode and the face's cmap. Without craft-fonts nothing
changes. Other CJK collections are untouched: the pinned craft-fonts
has only Japanese faces, and its later Chinese face is Noto CJK, which
AGENTS.md §1.1 rules out. pdfcraft-render now depends on pdfcraft-fonts
(L3 to L2).

Tests: raster::tests::non_embedded_japanese_cid_fonts_draw_with_a_craft_fonts_face
(with CRAFT_FONTS_DIR: 日本 in HeiseiMin-W3 and HeiseiKakuGo-W5 now
draws; it drew 0 dark pixels before; skips without craft-fonts, as the
Linux CI job has them) and raster::tests::japanese_font_names_pick_mincho_or_gothic.
The parity entry view.render-cid-fonts cites the test and notes what is
still missing.

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 19:39:26 -04:00
4995da0653 i18n: add Russian (ru) interface translation (#375)
* i18n: add Russian (ru) interface translation

- Add ru.tsv catalog (~1950 entries, clean-room translations following PhotoCraft terminology: Слой, Образцы, Обработка контуров, Монтажная область, Обводка, Заливка)
- Register ru in LANGUAGES with plural_russian (one/few/many with 11-14 exception)
- Add Russian tests: registration, command/catalogue coverage, UI literals, history/diagnostics, plural forms
- Add ATTRIBUTION.toml entry for ru.tsv
- Update docs/localization.md, ROADMAP.md with Russian language
- All i18n tests pass, cargo fmt and clippy clean

* ru: translate labels added on main since the catalog was written; Russian in the Latin-font coverage test

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* ru: '>' in the JavaScript-off hint, as the other catalogs (Inter has no ▸)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Brandon Thomas <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 19:24:51 -04:00
dcf81b4507 UI-POLISH: fix toast wrapping and Linux shortcut hint (#376)
Keep notices within the viewport and let short feedback recover its natural
width. Format the toolbar shortcut for the current platform.

Co-authored-by: sanyamsingh001 <[email protected]>
Co-authored-by: Codex <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 19:10:13 -04:00
5ef27ff678 M5: ink strokes are drawn as smooth curves through their points (#374)
#260 (page 7) compares PdfCraft with Acrobat, which draws an Ink
annotation's /InkList as a smooth curve through the points;
pdfcraft-annot drew straight segments between them (as MuPDF, Poppler
and PDFium do). A stroke of three or more points is now drawn as a
Catmull-Rom spline through every point, written as cubic Béziers: the
curve leaves each point parallel to the chord between its neighbours,
and an end uses itself as the missing neighbour. Two points stay a
line and one point a dot. This is the appearance PdfCraft writes for
its own ink, signatures drawn with Fill & Sign included, and, with the
display-only appearances for comments that have none, how ink without
/AP is shown.

A curve can swing beyond its points, so a new ink annotation's /Rect
now also covers the curve's control points (the curve stays within
them); before, only the points plus the line-width margin.

Test: annot tests::ink_strokes_are_smooth_curves_through_their_points
checks the exact curve for a three-point stroke, a line for two points,
a dot for one, and a /Rect that holds a stroke whose curve rises above
its highest point (22 on main, 23.667 now). The comment.pencil parity
entry cites it.

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 18:58:17 -04:00
4a50222258 Forms: round required-field border on radio buttons; Highlight fields is remembered (#372)
* Forms: round required-field border on radio buttons; Highlight fields is remembered

#260 (page 8) compares PdfCraft with Acrobat, which outlines required
checkboxes and radio buttons in red. Adobe's documentation says that
border shows "when the Highlight Existing Fields button is selected",
which PdfCraft already did (View: Highlight fields). Two differences
remained:

- The red border was a rectangle for every widget, so a round radio
  button got a square around its corners; Acrobat's follows the button.
  Radio buttons now get a round border and tint.
- Acrobat keeps Highlight existing fields as a preference, while
  PdfCraft forgot it for every document. The choice is now remembered
  for the next document and the next session (ViewDefaults and
  settings). It still defaults to off, and red borders still appear
  only while fields are highlighted.

Tests (view.rs): required_radio_buttons_get_a_round_red_border (the
widget's corner, outside the circle, is not red; on main it is) and
field_highlighting_is_remembered (a second document and a restored
session open highlighted; on main the second document didn't). The
form.highlight-fields parity entry cites both.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* view.rs: the field-highlight tests sit with the others (no merge conflict with #363)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 18:49:26 -04:00
2a35a1a76f M11: Optimize PDF and Reduce File Size run in the background with a progress bar (#370)
* M11: Optimize PDF and Reduce File Size run in the background with a progress bar

Advanced optimization and Reduce File Size did all their work on the UI
thread, so on a large file the window stopped repainting until they were
done and looked as if it had crashed.

- pdfcraft-optimize: optimize_with_progress reports each image and the
  clean-up; returning false stops with OptimizeError::Cancelled.
- engine: Session::optimize_job captures a copy of the document and the
  choices; OptimizeJob::run reports each OptimizeStage (removing user data,
  images, cleaning up, merging, writing), stops on request with
  EditError::Cancelled and turns a panic into an error so a worker always
  reports back. optimized_bytes is the job run in place.
- ui: both commands run the job on a worker thread (inline in tests and on
  the web), like OCR and Export. A card at the bottom centre shows the
  stage ("Optimizing... image 14 of 40"), a bar that eases towards the
  fraction with a light sweeping across it, the percentage and Cancel;
  notices stack above it. A second run is refused while one is going. The
  control channel's state includes the progress.

The headless doc_optimize and doc_reduce tools stay synchronous. New
strings are translated for es, fr, ja, zh-hans, zh-hant.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Clippy: as_chunks in the signature image background test (follow-up to #355)

#360 switched the image test to as_chunks; #355 added another chunks_exact(4)
in the background test, which clippy's chunks_exact_to_as_chunks rejects.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Optimize: report a failed worker spawn instead of waiting forever

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 18:46:34 -04:00
23bac79756 View: page rasters map texel for texel onto the screen (sharp text at any zoom) (#363)
#260 (page 9) reports text that looks softer than in Acrobat once zoomed.
The page was rendered at the zoom's device scale rounded to 1/64
(render_scale, to spare re-renders on tiny fit-width changes), and the
texture was stretched onto the page's layout rectangle, whose corner
usually isn't on a whole physical pixel. Every line and glyph went
through linear resampling: at 87 % on a 2x display the raster was 0.32 %
too small for its rectangle, and #260's page 9 lost 7.9 % sharpness
against a direct render (1.7 % at 137 %; 0 at 150 %, which happens to
quantize exactly).

The page now renders at the exact device scale (tags resolve 1/65536 of
a scale step instead of 1/1000), each page rectangle starts on a whole
physical pixel, and a raster at the current scale is drawn at its own
pixel size from there, whole page or tile. A raster from an older scale
(mid-zoom) and the low-resolution backdrop under tiles still stretch, as
before. With the fix, page 9 on screen matches a direct render exactly
(mean difference 0.00/255 at 87 % and 137 %, was 6.30 and 2.66).

Test: view.rs::page_raster_maps_one_to_one_onto_screen_pixels renders a
page of 0.5 pt lines at 87 % with 1 and 2 pixels per point and compares
the screen with the page rendered directly at the exact scale. On main:
mean difference 69.5/255, max 216. Now: under 1, max under 16.

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 18:23:45 -04:00
a747f2521f M2.6: W/W* clip after whichever path-painting operator ends the path (#362)
ISO 32000-2 §8.5.4: W and W* mark the current path to become the clip
once the path-painting operator that ends it has painted it with the old
clip, and n is only one such operator. The vendored interpreter applied
the clip in n alone. After S, s, f, F, f*, B, B*, b or b* it was never
applied, so everything painted afterwards ignored it, and it stayed
pending until some later, unrelated n (even after Q) clipped content
that should show. Issue #260's test file uses `W* S` on pages 3, 5 and
9: a shading meant for a circle flooded page 3, an image meant for a
rounded rectangle and nested clips on 5 and 9 spilled out.

Every painting operator now applies a pending clip after painting and
clears it (apply_pending_clip, shared with n). The now unused
Context::clip getter is removed.

Test: raster::tests::clipping_path_applies_after_any_painting_operator.
W and W* with each of n, S, s, f, F, f*, B, B*, b, b*: the later red fill
stays inside the square, and a stroking operator's outer half still
shows outside it (painted under the old clip). A clip used by S doesn't
linger for a later n, inside or after q/Q. On main it fails at `W S`.
MuPDF, Poppler and PDFium agree on every case. Page 3 of #260's file now
differs from PDFium by 0.84/255 on average (was 164). Vendored patch
(16).

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 18:17:34 -04:00
cyfung1031andClaude Opus 5.5 620e8a2d7b Add my contributor name (cyfung1031) (#364)
Adds my own entry to contributors/people.toml, as described in
docs/contributors.md ("Credit yourself").

Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 17:45:33 -04:00
f88a59f762 M10.2: Create PDF from multiple files, edited as pages in the Organize grid (#361)
* M10.2: create PDF from multiple files

Create a PDF ▸ Multiple files takes PDFs, images and .txt files, lets the
user reorder them, and makes one combined PDF (a bookmark and an optional
page range per file) or one PDF per file in a chosen folder, never
overwriting what is there.

- create: source_kind() tells PDFs, images and text apart (moved from the shell)
- engine: Session::convert_to_pdf, shared by Open, the dialog and the tool
- automation: doc_create_multiple (combine or separate)
- ui: Multiple files dialog reusing the Combine files list; translations
- parity entry and ROADMAP updated; catalog hashes refreshed

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* M10.2: multiple files open in the page grid; insert files at any gap

Create a PDF ▸ Multiple files now opens the picked files as one unsaved
document in the Organize page grid instead of a file-list dialog: pages
are removed and reordered there, and Save pages writes what is shown.

- grid: a "+" at every gap inserts files right there; Save pages button
- insert from file: several files in order, images and text converted,
  inserted pages selected
- the file-list dialog is removed; one PDF per file stays in the
  doc_create_multiple tool
- translations, catalog hashes, parity notes and ROADMAP updated

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* M4: insert files by dropping them on the page grid

On desktop, PDFs, images and .txt files dropped on the Organize page grid
are inserted at the gap under the pointer, in order, and selected; a
dropped file still opens as a document everywhere else.

winit does not report the pointer while files are dragged over the
window on every platform, so a drop waits (up to a second) for the
pointer to show up and otherwise appends at the end.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* M4: files dragged over the page grid follow the pointer (macOS)

winit sends no pointer moves while files are dragged over the window, so
egui kept the place the pointer entered at: the insertion bar froze there
and the files were inserted there. During a file drag the pointer is now
read from AppKit (safe objc2 calls, crates already in the tree) and fed
to egui, so the bar and a "+" badge follow the pointer and the files go
where they are released.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 17:42:13 -04:00
MarekSpodBiedryandBrandon Thomas 2f42c743b9 Issue #157: the Windows portable zip keeps settings, logs and recovery beside pdfcraft.exe (#325)
* Issue #157: the Windows portable zip keeps settings, logs and recovery beside pdfcraft.exe

The portable zip had no portable.txt, and the app had no portable mode: it always wrote %APPDATA%\PdfCraft and %LOCALAPPDATA%\PdfCraft. Now portable.txt (or PdfCraft.portable) beside the executable puts the settings, log files, crash recovery and new digital IDs in PdfCraftData next to it, as PhotoCraft does, and the zip ships portable.txt. An unwritable PdfCraftData falls back to the per-user folders and says so.

* Issue #157: update ATTRIBUTION.toml SHA-256 for the translation catalogs this PR changes

---------

Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 17:29:59 -04:00
Devon LlewellynandBrandon Thomas acb8e96aff Update image signatures live during resize and movement (#355)
* M5.7: update image signatures live during resize and movement

* M5.7: preserve image signature proportions when resizing corners

---------

Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 17:17:05 -04:00
Chiranjeevi U b5edb59d84 Clippy: as_chunks in the signature image test (follow-up to #335) (#360)
Signed-off-by: Chiranjeevi U <[email protected]>
2026-10-08 17:11:51 -04:00
69fa2ea9f8 Platform: one save-staging helper for automation and the desktop app (#356)
Follow-up to #319, from review. create_staging, staging_suffixes and
STAGING_ATTEMPTS were copied in pdfcraft-automation and pdfcraft-ui-egui,
which are both L7 and can't depend on each other. They now live once in
the new pdfcraft-platform crate (L7, std only), which layers.rs already
reserved with both sideways edges.

A pure move: the body is unchanged apart from a StagingName parameter
that keeps each caller's existing file name (.{name}.{suffix}.pdfcraft-tmp
for automation, .{name}.pdfcraft-{suffix}.tmp for the desktop save). The
doc comment on staging_suffixes now says the suffix is SipHash keyed from
the OS random source: enough that a name can't be planted in advance, but
not a CSPRNG.

New tests in the platform crate pin both name forms, the 128-byte stem
cut, the 16-name limit and refusal when no suffix is left. The callers'
planted-file, link, folder and failed-rename tests stay where they are.

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 17:07:00 -04:00
05c8ab3b3e M14: Telugu (తెలుగు) interface language (#349)
* M14: Telugu interface font

- The interface takes `Telu` faces from craft-fonts after the CJK and Arabic ones, on the web too
- Test: Telugu text has glyphs in every family and its conjuncts are shaped

Signed-off-by: Chiranjeevi U <[email protected]>

* M14: Telugu interface language

- Complete te catalog: 1,984 entries plus whole-phrase Undo/Redo; te and te_IN locales use it
- Undo and Redo labels use a catalog phrase when the language has one (Telugu puts the verb last)
- Tests, docs, attribution, parity and ROADMAP

Signed-off-by: Chiranjeevi U <[email protected]>

* Add my contributor name (chiranjeevi-max)

Signed-off-by: Chiranjeevi U <[email protected]>

* M14: catalog contexts for labels with two meanings

- tl_ctx! gives the signature pad's Type, the Action Wizard's Start and the comment menu's Edit their own context; Telugu translates them, other languages keep their current translation
- Preferences' All tools goes through the catalog in every language

Signed-off-by: Chiranjeevi U <[email protected]>

* M14: Telugu for the look-alike web address warnings

Signed-off-by: Chiranjeevi U <[email protected]>

* M14: Telugu for the image signature notices

Signed-off-by: Chiranjeevi U <[email protected]>

* Telugu for Open Recent (#323)

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Signed-off-by: Chiranjeevi U <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 17:00:25 -04:00
868bd727d1 M13: pdfcraft-cli mcp --compact lists 12 tools and finds the rest by search (#353)
`tools/list` returns all 132 tools (109,578 bytes, ~27k tokens), which an
agent pays on every session. With `--compact` (library:
`McpServer::with_compact(true)`) it returns the 10 core tools
(`mcp::COMPACT_CORE_TOOLS`) plus `tool_search` (query / category / name
with the full schema) and `tool_call` (runs any tool through the same
`Automation::call`): 12 tools, 7,697 bytes. `tools/call` by name keeps
working for every tool; without the flag nothing changes. Same shape as
`lightcraft-cli mcp --compact`; the meta tools are not called
`*_command` because "command" already means a registry command here.

Both meta tools reject unknown outer keys and report failures as
`isError` results; `tool_call` honours `--root` exactly like a direct
call. Tests: automation integration tests (compact list, discovery,
dispatch, errors, root confinement) and a CLI test that launches the
binary with and without `--compact`.

Co-authored-by: Oldrich333 <[email protected]>
Co-authored-by: Claude Sonnet 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 16:55:25 -04:00
dbe4b2dddb Issue #290: File ▸ Open Recent lists the recent files (#323)
* Issue #290: File ▸ Open Recent lists the recent files

The Home view kept a recent-files list but the File menu had no way to
reach it; Acrobat shows File ▸ Open Recent and the request asked for
exactly the menu wiring.

A new command file.open_recent renders as a submenu of the live list
right under Open… (disabled while the list is empty); each entry opens
its file or focuses the tab already showing it, which is now shared
with the Home view's list through the new open_recent() instead of a
second copy of that check. The command palette runs it as "open the
most recent file", or says there are none. Translations added to every
catalog (Japanese, Czech, Spanish, both Chinese and Brazilian
Portuguese are test-covered).

Test: commands.rs::the_open_recent_menu_lists_files_and_opens_one
(submenu lists a seeded recent file and clicking it opens a new active
tab on that path) and commands.rs::the_open_recent_menu_is_disabled
while_the_list_is_empty. Both failed before the change (no such menu).

Co-authored-by: Mawfyy <[email protected]>

* Build: cap cargo jobs and lighten the dev profile

On a 7.1 GiB machine the default one-job-per-core (12) with every
dependency at opt-level 2 plus full debuginfo swap-thrashes the box
frozen mid-build. jobs = 4 bounds peak memory to a few GiB and matches
GitHub runners (4 vCPUs), so CI is unaffected; dependencies drop to
opt-level 1 with debug = false, which halves their build cost and
keeps them fast enough for a usable debug app. Own crates keep their
opt-level and full debuginfo.

Verified: a from-scratch rebuild of all dependencies peaked at ~2 GiB
used with the machine responsive throughout; the perf.rs frame-budget
tests still pass at the lower dependency optimization.

Co-authored-by: Mawfyy <[email protected]>

* Keep the build configuration as on main; French for Open Recent

The jobs and dependency opt-level changes are a separate build-policy decision.
French is coverage-checked since #291; catalog checksums refreshed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* French for Open Recent again, and catalog checksums refreshed

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Mawfyy <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 16:46:22 -04:00
Devon Llewellyn e17833a64e Add image signatures with placement preview and resize controls (#335)
* M5.7: import images as Fill & Sign signatures and initials

* M5.7: preview image signatures and select after placement
2026-10-08 16:36:26 -04:00
f540035db3 Issue #124: a long page label no longer overlaps its bookmark title (#328)
* Issue #124: a long page label no longer overlaps its bookmark title

The Bookmarks panel painted the destination's page label right-aligned
with no width limit, while the title's wrap width reserved a fixed 36
px for it. Drawing tools put whole section titles in /PageLabels (the
reporter's file uses "Floor Plans (001 Floor Plans): SITE PLAN" as both
title and label), so the label painted straight over the title.

The label now gets a bounded column (72 px) and is ellipsized on
character boundaries by a pure ellipsized_prefix helper; the title
wraps to the width the column really takes. Short labels ("3", "iv",
"1-1") are unchanged, and a label with no page still shows nothing.

Test: panels.rs::label_column (short labels untouched, long labels cut
to the column with an ellipsis and stay a prefix of the real label,
CJK cut on char boundaries, the loop ends when nothing fits). The
overlap itself is verified against the reporter's file (headless shot
of the Bookmarks panel).

Co-authored-by: Mawfyy <[email protected]>

* Bookmark labels: measure at most 64 characters of a page label

A page label is document text; ellipsizing a huge one character by character laid out
thousands of candidates per row per frame.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Mawfyy <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>
2026-10-08 16:31:31 -04:00
bb8fcd006e Security: refuse mailto attachments, show link hosts in punycode (follow-up to #104) (#337)
* Security: refuse email links that attach or insert a local file

Follow-up to #104. A document's mailto: link could ask the email app to
attach a file from the user's computer (Evolution, KMail and Claws Mail
honour attach=, Evolution and KMail also attachment=) or read one into
the body (Claws Mail's insert=).

document_url now refuses a mailto: address in which any word starting
with attach or insert (any case) is followed by =, wherever it stands
and after each layer of percent-decoding. It also refuses text that
some email tools decode before reading the address: RFC 2047 encoded
words, which KMail decodes across the whole address, and backslash
escapes, which xdg-email's echo decodes. The link is refused rather
than rewritten: PdfCraft doesn't change what a document asks to open,
and the email apps' parsers disagree with one another.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Security: show a link's host as the browser receives it, in punycode

Follow-up to #104. The link prompt's host now comes from
links::display_host, which reads it with url::Url: the webbrowser crate
hands the OS that crate's serialisation, and the web build's browser
parses by the same WHATWG standard. International hosts are shown in
punycode with a note, a label mixing writing systems (UTS #39 resolved
script sets) gets a red warning, numeric hosts such as 3232235777 show
as 192.168.1.1, and a host the browser would reject is refused as
malformed. The Unicode form isn't repeated in the prompt, so a
whole-script lookalike can't read as the real site.

url, idna and icu_properties become direct dependencies of
pdfcraft-engine; all three were already in the graph.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Security: refuse document addresses the URL parser rejects

Follow-up to #104. egui opens links through the webbrowser crate, which
parses the address with url::Url and, when that fails, treats it as a
local file path and opens file:///<cwd>/<address> in the browser.
document_url accepted addresses that don't parse, such as
mailto://a^b/x or https://a^b/ (a forbidden host code point), so a
document could still get the browser to open a local path.

document_url now also requires url::Url to accept the address with the
same scheme, which is exactly the parse webbrowser does first.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 16:07:25 -04:00
130b7ea06c Security: print jobs, new digital IDs and the --control file no longer write through planted links (#338)
* Security: pipe print jobs to lp instead of a shared temp folder

On macOS, Linux and FreeBSD, Print wrote each job to
<temp>/pdfcraft-print-<pid>/job-<time>.pdf and passed that name to lp.
The folder name is predictable and was made with create_dir_all, which
accepts a folder another local user created first in a shared /tmp and
follows a symlink planted there; the job was then written with fs::write.
That user could read every printed document, or swap the file before lp
read it. The folder was also never removed.

The job now goes to lp on stdin, so nothing is written to disk. lp_args
no longer takes a file. The job is fed on its own thread while lp's
output is collected, so neither side can block on a full pipe; if that
thread can't be started, lp is stopped and an error returned rather than
a panic. When lp refuses a job before reading it (an unknown printer)
the user sees lp's message rather than a broken pipe. CUPS ends its reply
for a job read from stdin with "(0 file(s))", which reads as if nothing
was sent, so that is dropped from the message shown.

submit_via takes the spooler command so tests can run this test binary
as a stand-in lp on every platform; the new test failed on the old code
(it received the temp file as an argument and nothing on stdin).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Security: create a new digital ID file fresh, owner-only

Configure New Digital ID > Create picked the first free name with
`!p.exists()` and then wrote the .p12 with fs::write. That is
check-then-write: a file or link planted at the name between the two is
written through. exists() also follows links, so a dangling symlink
looked free and the private key was created wherever it pointed. The
file got default permissions, readable by other local users on most
Unix systems.

save_new_id_file now creates the file with create_new, never opening
anything already at the name, and with mode 0o600 on Unix. A taken name
moves on to the next ("<name> 2.p12", ...), including a folder, which
Windows reports as access denied rather than already exists. A failed
write removes the partial file.

The dangling-link test failed on the old code (the key was written
through the link); the hard-link and folder test guards the retry loop,
and a Unix-only test checks the 0o600 mode.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Security: never write the --control token through a planted link

write_control_file opened the --control path with create + truncate. A
symlink or hard link already at that path was followed: its target was
truncated and overwritten with the control token before set_permissions
ran, so the token could land in a file another user can read, and any
file the link pointed at was destroyed.

The JSON now goes to a fresh file next to the path, with a random name
(create_new, 0o600 on Unix, another name if one is taken, including a
folder on Windows), which is then renamed over the path. The rename
replaces a link instead of following it, a control file left by an
earlier run is still replaced as before, and a reader polling for the
file never sees it half-written. A failed write or rename removes the
temporary file.

The hard-link and symlink tests failed on the old code (the token was
written into the linked file); a third test covers replacing a previous
run's file, and the owner-only mode on Unix.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Contributors: credit jcl-bit as James Locke

My own entry in contributors/people.toml (AGENTS.md, Contributor
credits), added in my PR as asked there.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 16:04:48 -04:00
a2d92daa00 Issue #263: combine, extract and split keep the PDF/X output intent and identification (#334)
Combine, extract and split built the new document from copies of the
pages and carried bookmarks, fields, layers, attachments and four Info
keys, but not the catalog's /OutputIntents, the GTS_PDFXVersion,
GTS_PDFXConformance and Trapped Info entries, or the XMP pdfxid
identification. A PDF/X file stopped being one, and a RIP or preflight
lost the intended output condition.

Extract and split now carry the output intents (with their ICC
profiles, through the same object map as the pages), the Info entries
(the version read from Info, else XMP) and a new XMP packet holding the
identification, trapping and title. The source's packet is not copied:
it can claim standards the new file no longer meets, such as PDF/UA,
whose structure tree is not copied. Combine carries the first source's
standard only when every source declares the same version, trapping
and output intents (type, condition and profile bytes).

Not yet: a warning when combine's sources disagree, and XMP dates.

Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 16:04:03 -04:00
a21637c757 M14: reject invalid combine page selector types (#329)
Validate every doc_combine selector before reading inputs or changing output and session state. Cover invalid types and saved/reopened selection order.

Co-authored-by: sanyamsingh001 <[email protected]>
Co-authored-by: Codex <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 15:55:42 -04:00
ca9541069f Issue #236: the Save-changes prompt shortens very long names to fit the window (#322)
Wrapping the title (#161) kept the prompt narrow, but a long enough name
still grew it taller than the window and pushed Save, Cancel and Don't
save off-screen. On the web a `?file=` URL names the document, so the
name has no length limit.

Past 80 characters the name now gives way in the middle ("start…end"),
keeping the start and the extension and version suffix; the full name
shows on hover. The new test checks the title and buttons stay inside
the desktop's minimum window (820×520) for long Latin, Thai and CJK
names and a 2000-character one.

Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 15:37:21 -04:00
9140b44792 M4: Combine files in its own tab, with a sortable table and unlocking of protected files (#321)
* M4: Combine files in its own tab, with a sortable table and unlocking of protected files

Combine files was a modal dialog with a cramped list and up/down buttons on
every row. It is now a tab next to Home and the documents, showing a table
of the files: File name | Pages | Size | Modified | Warnings.

- Columns sort when their heading is clicked (anywhere in the cell; again to
  reverse; names in natural order), resize from their edges and move by
  dragging the heading. Order and widths are kept in the settings; a
  right-click on a heading resets them.
- Rows select like a file manager (click, Ctrl/Cmd+click, Shift+click,
  Shift+arrows, Ctrl/Cmd+A). One toolbar moves, removes and unlocks the
  selection; Alt+arrows and dragging move it too. Every change to the list
  undoes and redoes with Cmd/Ctrl+Z (also toolbar buttons).
- Add files, Add folder, Add folder and subfolders (a split button), Add open
  documents, or drop files and folders on the tab.
- Problems show before Combine: password-protected files, security settings
  that withhold page assembly, page ranges (checked as typed, with the pages
  they take), duplicates. Files that open but are protected say that the
  combined file won't keep their security; the result is never encrypted.
- Unlock... asks for a file's open or permissions password (one password can
  be tried on several files). Passwords stay in memory, are never printed,
  and reach the engine through combine_unlocked; doc_combine takes them as
  `passwords`. The engine decides whether a password works, since the
  inspector rejects some it accepts (RC4 owner passwords).

organize.combine-sort is shipped and organize.combine-options partial
(include open files). Strings are translated for es, fr, ja, zh-hans, zh-hant.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Credit Marlon Konrad (mlkonrad) in the About window

Adds my own entry to contributors/people.toml, as docs/contributors.md asks.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 15:37:10 -04:00
f70c4caac9 Security: create save staging files with create_new (follow-up to #164) (#319)
* Security: create the --root staging file with create_new

Follow-up to #164. write_atomic staged every save at the fixed name
.<name>.pdfcraft-tmp and wrote it with fs::write, which follows a
symbolic link and writes through a hard link. So a link planted there,
in a folder someone else can write to, redirected the bytes to any file
the link pointed at.

The staging file now gets a random 64-bit suffix (std's RandomState,
keyed from the operating system's random source) and is opened with
OpenOptions::create_new, which fails if anything already has the name
(a file, a hard link, a symbolic link even when dangling), on Windows
(CREATE_NEW) as on Unix (O_EXCL). A taken name is skipped, never
opened; Windows reports a folder at the name as "access denied", which
counts as taken when something is there. After 16 taken names the save
fails and nothing is overwritten. A failed write or rename removes only
the file this save created. At most 128 bytes of the target's name go
into the staging name, so it fits every system's name limit.

The #164 tests that planted a sentinel at the old fixed name now also
compare folder listings, and say that the "is a folder" refusal is what
they check.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

* Security: create the desktop app's save staging file with create_new

The same fix as the previous commit, for the desktop app.
editing::write_atomically, which Save, Save As, Export, Print to PDF,
signing and crash recovery all use, staged at
.<name>.pdfcraft-<pid>.tmp and opened it with File::create, which
follows a symbolic link and writes through a hard link. A process id is
easy to guess, so a link planted beside a document in a shared folder
could redirect a save into another file.

The staging file now gets a random 64-bit suffix and is opened with
OpenOptions::create_new; a taken name (on Windows, a folder reports
"access denied") is skipped, never opened, and after 16 the save fails
without overwriting anything. At most 128 bytes of the document's name
go into the staging name.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

---------

Co-authored-by: Claude Opus 5.5 <[email protected]>
Co-authored-by: Brandon Thomas <[email protected]>
2026-10-08 15:19:16 -04:00