The pinned integration consumes native clipboard shortcut keys and delivers PasteImage pixels. Handle those payloads in order, keep text cache invalidation, and use the delivered image even if the OS clipboard changes before processing. Preserve alpha and validate dimensions and byte counts before allocation.
Remove release timestamps so Windows clipboard history cannot reuse a completed paste gesture. Keep explicit shortcut fallback for control-channel and browser internal-image paste, with modal, focus and permission guards unchanged. Tests cover both release orderings, history after prior paste, mixed batches and duplicate prevention.
Co-Authored-By: Codex GPT-6.1 <noreply@openai.com>
Menu paste refuses cached images when system text supersedes them. Keyboard and menu paste share the text check; image validation reuses Create. Expire shortcut context by elapsed time even when frames are sparse. Regression tests fail with the old checks restored.
Co-Authored-By: Codex GPT-6.1 <noreply@openai.com>
Includes #4325#1952#4180#2529#4320#4805, preserving their original histories.
Keep paragraph alignment and hard/soft wrap metadata together; retain CCITT/downsampling/RGB ownership guards with bounded JBIG2 export and exact-copy symbol encoding.
Combined interaction regressions added. Validation pending.
Use a named compact preset arrow beside the field, retain the row alignment/width assertions for the editable control, and open the current colour flyout in the saved-text regression. No accessibility or layout checks are disabled.
Four holes CodeRabbit found on 648dd428:
- alignment_frame framed a one-row paragraph when any alignment entry
was set, including one past the draft's rows, and then moved rows
with no alignment of their own to the column's edge. It now takes the
draft and frames only when every draft row is aligned, by its own
alignment or the paragraph's.
- remap could not tell which of two same paragraphs an edit took
("A\nA" to "A"), and kept the deleted one's alignment. remap_at takes
the caret where the edit ended, and the typing path (follow_typing,
both editors) passes it from the box's state. The caret only chooses
between readings that fit both texts.
- Both editors judged a focus loss by where a click landed, so focusing
a Format text control by keyboard or a screen reader (no pointer)
closed the box before the alignment was chosen. They now also judge
by where the keyboard went (focus_pos): focus outside the document
view, or on the added-text box's own buttons, keeps the box open as a
click there does.
Each change has a test seen failing before it.
restyle_draft applies a format change to an open added-text box in
place, so the page then has the box's text. Unlike a paragraph's
applied(), it left typing_from as it was: when the restyle left the
text as it was, the box kept its history, and Redo put typing undone
before the restyle back on top of it, to be saved on finishing. It now
resets typing_from after a successful edit, so the next claim clears
the history (and the rows' alignments by text with it).
Main moved to egui 0.37 (#4591) and took the menus change (#4752).
Conflicts:
- edit_text_ui.rs: the paragraph box keeps the shared input id, now
Id::unique; the added-text box's shared id and the unit tests' ids
follow.
- content_ui.rs: the added-text box keeps its per-paragraph layouter
(which places each line itself, so main's .align(halign) is left out)
and takes main's inset, margin(4, 2), and its "Added text"
accessibility label.
Main moved to egui 0.37 (#4591) and renamed string ids to Id::unique.
Conflict in edit_text_ui.rs: the paragraph box keeps the shared input
id, now Id::unique; the added-text box's shared id follows.
* M7: a moved text box's drag preview shows the box alone (#4464)
While an added text box or picture was dragged, the pixels that followed
the pointer were cut from the page raster inside the item's box, so
whatever the box covered at its first place (a filled shape, a picture,
other text) was carried along with it.
The drag now renders the item alone too: a copy of the document whose
page keeps only the item's own content stream and no annotations, drawn
on a transparent page (`pdfcraft_edit::isolate_content`,
`Document::added_content_alone`). Those pixels follow the pointer over
the page rendered without the item, so what it covered stays put. The
preview shows once both rasters are in; until then the item stays where
it is, as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0175FWj4xFhMhSH3UpMU8DSC
* M7: drop the move preview's earlier rasters when a re-render fails (#4464)
When the scale changed after both the page-without-item and item-alone
rasters were in, and a render at the new scale failed, only the renderers
were cleared. The old textures stayed, so the item kept following the
pointer from them although the preview had given up. A failure now clears
both texture slots too, so the item stays where it is while dragged.
The receive step moves into its own method so a test can drive it with a
pool whose renders always fail.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0175FWj4xFhMhSH3UpMU8DSC
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Three holes in the shared text box's history:
- Formatting applied with the paragraph open left typing_from as it
was, so when the format left the text unchanged the box kept its
history, and Redo put typing undone before the format back on top of
it. applied() now resets typing_from, so the next claim clears it.
- Undo or Redo from the menu in the same frame as a tab switch ran
before the box was drawn, on the history of the other tab's box: Undo
put tab B's text into tab A's box, and Redo put A's undone typing into
B's. undo_in_page_box and redo_in_page_box now make the box claim the
text box first (claim_typing), as drawing it does.
- A box new to the text box cleared only the last box's history and
kept its caret and selection; it now starts from a default state.
claim_typing on LineEditor and TextDraft is now the one way a box takes
the text box, for drawing and for the menu.
Carried from #4179 (aa326f37). On this branch the rows' alignments by
text restart with the history, so a Redo past a format can't bring
back an alignment from before it.
Three holes in the shared text box's history:
- Formatting applied with the paragraph open left typing_from as it
was, so when the format left the text unchanged the box kept its
history, and Redo put typing undone before the format back on top of
it. applied() now resets typing_from, so the next claim clears it.
- Undo or Redo from the menu in the same frame as a tab switch ran
before the box was drawn, on the history of the other tab's box: Undo
put tab B's text into tab A's box, and Redo put A's undone typing into
B's. undo_in_page_box and redo_in_page_box now make the box claim the
text box first (claim_typing), as drawing it does.
- A box new to the text box cleared only the last box's history and
kept its caret and selection; it now starts from a default state.
claim_typing on LineEditor and TextDraft is now the one way a box takes
the text box, for drawing and for the menu.
The tabs share one text box, and its Undo history was cleared whenever
another document's box took it: opening a paragraph in tab B wiped tab
A's typing steps, so Edit ▸ Undo back in A found none and closed A's
paragraph instead of taking the typing back. The box being left now
keeps a copy of its history and caret aside, under its document, and
the same box gets it back on its return; a box new to the text box
still starts with none, so typing still never reaches another tab. The
copy is a deep one: a state's history is shared between its clones.
Carried from #4179 (abc378c0). On this branch the rows' alignments by
text go aside and come back with the history, so Undo after the trip
still restores a deleted row's alignment.
The tabs share one text box, and its Undo history was cleared whenever
another document's box took it: opening a paragraph in tab B wiped tab
A's typing steps, so Edit ▸ Undo back in A found none and closed A's
paragraph instead of taking the typing back. The box being left now
keeps a copy of its history and caret aside, under its document, and
the same box gets it back on its return; a box new to the text box
still starts with none, so typing still never reaches another tab. The
copy is a deep one: a state's history is shared between its clones.
egui's typing history keeps only text and caret, so Undo bringing back
a deleted row or line (added text, or a paragraph) gave it the
alignment of the row before it, and finishing the box could save that.
Each page box now keeps the texts it has shown through its own typing,
with every row's alignment then (follow_typing): Undo or Redo back to
one of them restores those alignments, and a new text follows the edit
with remap. An alignment picked since makes the older ones stale; they
are dropped, so Undo never takes back a pick. The record is cleared
with the box's typing history and holds 100 texts, as egui's does. It
covers typing, the keys and the menu's Undo and Redo.
On this branch the two-tab test also runs the menu's Redo in the copy,
where the box, with no Redo of its own, passes the step on and closes;
that step no longer requires the editor to stay open.
Also carries #4179's stronger two-tab test (dd47c4f9): the copy's
paragraph must be open before the key Redo and after it.
Edit ▸ Undo with typing in a paragraph or added text box that the page
doesn't have yet applied the typing (a new edit, which dropped the
document's waiting Redo), closed the box and undid the typing all at
once; the key takes it back a step at a time in the box. Menu Undo now
goes to the box first, as Redo does, and is enabled while the box holds
such typing. Undo and Redo share typing_step for the box's own history.
Edit ▸ Undo with typing in a paragraph or added text box that the page
doesn't have yet applied the typing (a new edit, which dropped the
document's waiting Redo), closed the box and undid the typing all at
once; the key takes it back a step at a time in the box. Menu Undo now
goes to the box first, as Redo does, and is enabled while the box holds
such typing. Undo and Redo share typing_step for the box's own history.
Edit ▸ Redo and the toolbar button followed only the document's Redo.
After Undo in a paragraph or added text box took the typing back, with
no document step to redo, they stayed disabled and only the key could
put the typing back. Redo is now also enabled when the box open on the
page has a Redo of its own: the step redo_in_page_box takes. It doesn't
ask for the box's focus, which the menu has taken by then.
Edit ▸ Redo and the toolbar button followed only the document's Redo.
After Undo in a paragraph or added text box took the typing back, with
no document step to redo, they stayed disabled and only the key could
put the typing back. Redo is now also enabled when the box open on the
page has a Redo of its own: the step redo_in_page_box takes. It doesn't
ask for the box's focus, which the menu has taken by then.
Main brought #4178 (already on this branch), #4217 (edited text keeps
every space typed), #4266 (added text takes character spacing) and
#3546 (Save commits the open text boxes).
Conflicts:
- edit/added.rs: AddedText has both aligns and char_spacing. Lines are
measured with the spaced width (latin_width) and placed by their own
paragraph's alignment, with Tc set before them; both are read back.
- edit/text.rs: wrap keeps #4217's spacing and still returns each
line's row, so a row aligned on its own keeps its alignment; a
justified row stretches over its interior spaces only.
- ui-egui/content_ui.rs: the box keeps its per-paragraph layouter,
which now draws character spacing (spaced_job), with input_id() and
the per-document typing history.
- automation: aligns and char_spacing are both text-only options.
- Tests from both sides kept; #4178's two editor tests, present on both
sides, kept once, and mode_tab's doc comment put back.
The TextDraft literals from #3546 take selection and typing_from, and
an engine test's AddedText takes aligns. New test:
added_text_paragraphs_align_by_their_spaced_width, seen failing with
the unspaced width.
Conflicts:
- content_ui.rs: main's added-text editor (alignment, character
spacing) kept whole; the box takes input_id() instead of an id_salt,
and its Undo history is reset per document by forget_typing_before.
- tests/it/editing.rs: both sides' new tests kept.
#3546's TextDraft literals (editing.rs, edit_text_ui.rs tests) take
typing_from: None.
Redo from the menu or toolbar closed the box first, which applied its
typing: a new edit that dropped the document's waiting Redo, and the
Redo itself then failed. The step was gone. Redo now goes to the box as
the key does: what Undo took back there comes back, and typing the page
doesn't have yet stays as it is, with the document's Redo waiting.
A new text box the document refused was put back without the request
to select the item once it exists, which stayed behind. It is put back
with the box.
Carried from #4179 (632ba10e). This branch already routed the menu's
Redo to the box; the test from #4179 covers what its own
redo_from_the_menu_puts_the_typing_back_in_the_box did, so that one
goes.
Redo from the menu or toolbar closed the box first, which applied its
typing: a new edit that dropped the document's waiting Redo, and the
Redo itself then failed. The step was gone. Redo now goes to the box as
the key does: what Undo took back there comes back, and typing the page
doesn't have yet stays as it is, with the document's Redo waiting.
A new text box the document refused was put back without the request
to select the item once it exists, which stayed behind. It is put back
with the box.
crates/engine/src/lib.rs: union of the added:: re-exports (paste_place/paste_rect from #4230, CHAR_SPACING_LIMIT).
crates/ui-egui/src/content_ui.rs: editor keeps #4178's anchored width and horizontal_align and #4266's spacing layouter; spaced_job takes the alignment so the custom layouter keeps it.
crates/ui-egui/tests/it/content.rs: kept both tests.
* Tests: UI tests wait for background work by time, not frame count (#4186)
A frame count is not a time: on a busy runner the worker had not finished
the open, or the page text had not arrived, within 30 frames or 50 hover
rounds. support::step_until (#[must_use]) steps frames until a condition
holds or 30 s pass, sleeping briefly between frames, and says whether it
held; each test asserts on that with its own message.
- control_open_replies_pending_while_the_worker_opens_and_focuses_once_it_has
and mode_tabs_keep_the_hand_over_page_text_scrolled_under_them wait with it,
and so does control.rs call() for its reply.
- support::settle waits for every pending render and fails if the pages are
not rendered within 30 s. It replaces all the render-pending settle loops
(40 to 3000 frames) and the local settle/wait_for_pages wrappers, except
text_select's double-click wait, which is held to 8 frames on purpose to
stay inside egui's multi-click window, and view.rs's loops that already
wait by a deadline.
- wait_until is built on step_until, keeping its diagnostic message.
- tabbing_back_to_the_same_field_then_saving_keeps_the_committed_value already
waited 30 s for its file. It failed because its "same-frame" case shared
its scratch directory with typing_and_saving_in_the_same_frame_saves_the_last_keystrokes,
which runs in the same test process (since ee1ee704, #1045) and deleted
the directory mid-save. forms' and pickers' scratch() now give every call
a directory of its own.
Fixes#4186
* M14: update ctutils to 0.4.5 for RUSTSEC-2026-0385
The dependency-advisory gate rejects ctutils 0.4.2 (non-constant-time
mask generation and u128 comparisons, fixed in 0.4.4). It comes in
through crypto-bigint for the signing crates. Only its version and
checksum change in Cargo.lock.
(cherry picked from commit 1f8811761a)
The paragraph box, and the added-text box, each keep one Undo history under
one egui id, shared by every tab. A box cleared it when it opened on new
text, but a box in another tab on the same text (two copies of a document)
kept it: typing taken back with Undo in one tab came back with Redo in the
other, from the key or from the menu. The document that last used the
history is now kept beside it, and the history is cleared whenever another
document's box takes it over.
Tests: the paragraph and added-text cases, each with two copies of a
document open; the paragraph case tries the menu's Redo too.
The paragraph box, and the added-text box, each keep one Undo history under
one egui id, shared by every tab. A box cleared it when it opened on new
text, but a box in another tab on the same text (two copies of a document)
kept it: typing taken back with Undo in one tab came back with Redo in the
other. The document that last used the history is now kept beside it, and
the history is cleared whenever another document's box takes it over.
Tests: the paragraph and added-text cases, each with two copies of a
document open.
- A row aligned on its own lost its alignment when the paragraph was then
given a colour, size or font: the rewrite left the rows' alignments out
once they had been applied. They now go with every rewrite.
- egui drops a box's selection while the box is unfocused, so after one
alignment or format a second choice went to the whole paragraph or box.
The selection is given back when formatting returns the focus.
- Redo from the menu or toolbar applied the box's typing first, a new edit
that dropped the document's Redo. It now redoes in the box, as the key does.
Finishing a box trimmed its text before comparing it with the item, so
an unchanged box whose text was saved with trailing spaces finished as
an edit. Before an Undo or Redo step that edit was applied, clearing
the document's Redo. A box matching its item is now no edit.
The editor of a box narrower than its 60-point minimum was anchored by
the box's own alignment. A box whose lines are all right-aligned (or
centred) on their own while the box stays Left wasn't anchored, so its
text was placed against the wider editor's edge, past the box. The
lines are now compared with each other and the editor keeps the edge
they share.
The editor is at least 60 points wide on screen, so a short box can be
clicked into. With the box's alignment applied, right-aligned or centred
text in a box narrower than that was placed against the wider editor's
edge, past the box's right edge. The editor now reaches past a narrow
box away from the edge its text keeps, so the text stays where the page
draws it.
With typing undone in a paragraph or added text box, its text matches
the page again, so Undo and Redo went to the document. Redo then closed
the box and redid a document change (or nothing), instead of putting the
typing back as the box's own Redo did before. And Shift+Cmd+Z is also
Cmd+Z to the Undo shortcut, so even a Redo the box kept was taken as a
document Undo.
Redo stays with the box while its own history has typing to put back
(the test egui makes when it handles the key), and Shift+Cmd+Z is never
a document Undo.
Format text's alignment always re-aligned the whole paragraph or added
text box, and clicking it closed an added text box, losing the
selection, so one line couldn't be aligned. With text selected,
alignment now applies to the lines (text between line breaks) the
selection touches; with only the caret, to the whole box as before.
- Added text stores each line's alignment in its /PCAdded parameters
(/Aligns, null where a line follows /Align). A justified line's last
row is not stretched.
- An edited paragraph sends its rows' alignments with each rewrite
while it is open (BlockStyle::aligns), in both the single-style and
the styled-region rewrite.
- Both editors draw each line by its own alignment, and the alignment
buttons show the selected line's. An added text box stays open while
Format text is used, its style applied at once; clicks are judged by
where they were pressed, so a touch or pen tap on the panel doesn't
close either editor.
- Automation: `aligns` on page_add_text, content_update and text_edit.
Opening a centred or right-aligned Add text box drew its text at the left
edge, a layout the box never had, and Ctrl+Z inside the box (which goes to
the text, not the document) left it showing that way. The editor now lays
the text out with the box's alignment. Justified text is still shown
left-aligned while editing (TextEdit can't justify).
Finishing a box trimmed its text before comparing it with the item, so
an unchanged box whose text was saved with trailing spaces finished as
an edit. Before an Undo or Redo step that edit was applied, clearing
the document's Redo. A box matching its item is now no edit.
The editor is at least 60 points wide on screen, so a short box can be
clicked into. With the box's alignment applied, right-aligned or centred
text in a box narrower than that was placed against the wider editor's
edge, past the box's right edge. The editor now reaches past a narrow
box away from the edge its text keeps, so the text stays where the page
draws it.
With typing undone in a paragraph or added text box, its text matches
the page again, so Undo and Redo went to the document. Redo then closed
the box and redid a document change (or nothing), instead of putting the
typing back as the box's own Redo did before. And Shift+Cmd+Z is also
Cmd+Z to the Undo shortcut, so even a Redo the box kept was taken as a
document Undo.
Redo stays with the box while its own history has typing to put back
(the test egui makes when it handles the key), and Shift+Cmd+Z is never
a document Undo.
Opening a centred or right-aligned Add text box drew its text at the left
edge, a layout the box never had, and Ctrl+Z inside the box (which goes to
the text, not the document) left it showing that way. The editor now lays
the text out with the box's alignment. Justified text is still shown
left-aligned while editing (TextEdit can't justify).
* Build each crate's integration tests as one binary
Every tests/*.rs file is its own executable that links the whole crate
graph. Move each crate's test files into tests/it/ as modules of one
tests/it/main.rs, for apps/pdfcraft, apps/pdfcraft-cli, automation, cos,
crypt, engine, render, sign and ui-egui. ui-egui's ui_group binary and
the support modules move into tests/it/ too. Crates with a single test
file keep it. The test executables go from 150 to 52, and every crate
runs the same number of tests as before.
ui-egui perf keeps its own binary (own process): its frame-time budgets
would charge each measurement for the other tests running beside it.
What the move needs:
- include_str!/include_bytes! and #[path] paths gain one "../".
- ui-egui: one GPU lock in tests/it/main.rs replaces the five per-file
ones (content, document_links, editing, fill_sign, view), so one
process creates one wgpu device at a time. The drop-line test in ui.rs
and the screenshot blocks behind PDFCRAFT_*_SHOT(S) and
CRAFT_UI_DOCKING_DIR, which render without holding it, take it too.
- pdfcraft winit_wayland_scroll: the vendored winit source it compiles
names crate::event, so that shim lives in main.rs.
- parity evidence names the new paths.
* Name the one-binary test paths in docs and comments
- READMEs, docs, ATTRIBUTION and source comments name tests/it/<file>.rs.
- The oracle README's example filters with --test it encryption::qpdf_agrees.
- pdfcraft's GPU lock comment points at the UI tests' shared lock in
crates/ui-egui/tests/it/main.rs.
