An auto-sized (`0 Tf`) single-line text field drew at most 12 pt however
tall the box. Acrobat Reader draws it at the size the height gives (checked
black-box on a synthetic form: 30 pt and 60 pt fields); ISO 32000-2
§12.7.4.3 leaves the size implementation-defined. auto_text_size_by now
keeps the existing height / 1.15 size without the 12 pt cap, still shrinks
to the width and never goes under 4 pt, with the height bounded at 14,400
(MAX_AUTO_HEIGHT, the largest page side ISO 32000-1 Annex C recommends).
Multiline and comb auto-size keep their 12 pt cap: not yet checked against
Acrobat.
Tests: the forms unit tests now pin a tall box's size (they pinned 12 pt),
and an automation test fills a 30 pt field through form_fill and measures
the drawn text with text_find. All three fail with the cap restored.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
A form XObject or annotation appearance with more `Q` than `q` popped
graphics states saved by the content that drew it, so later page text,
paint and clip lost the page's `cm` and clip, and search redaction of that
text failed closed at `redact_apply`.
A content stream balances its own `q` and `Q` (ISO 32000-2 §8.4.2,
§8.10.1). Vendored hayro-interpret patch (68): `interpret()` records the
state depth at which its stream starts (`Context::enter_stream`) and
restores the outer floor on exit; a `Q` at the floor is ignored with a
warning. Page content (`interpret_content`) is unchanged.
Tests: pdfcraft-render `it::stray_q_in_a_form` (three behaviour tests fail
with the fix reverted, one guard) and pdfcraft-automation
`it::redact_after_stray_q_form` (end to end; fails at `redact_apply` with
the fix reverted).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
The vendored hayro-interpret kept the text and text line matrices in the
saved graphics state, so a `q … Q` inside BT … ET put the pen back where it
was before `q`. Text after the `Q` was drawn, extracted and found at the
wrong place, and search redaction refused to apply because its find boxes
(from the render text layer) disagreed with the redactor's own measurement.
Tm and Tlm are not graphics state (ISO 32000-2 §8.4.1 Table 51, §9.4.1);
q/Q inside a text object is allowed in PDF 2.0 (§8.2). Patch (67) carries
them across the restore; font and the other text parameters are still
restored. Forms and annotations save and restore around their own content,
and Type 3 glyphs, patterns and soft masks run in a context of their own, so
a stream's pen does not reach its caller unless the stream pops past its own
saves (two or more stray Q in a form already corrupt the page state on main;
unchanged here).
Tests: pdfcraft-render it::text_matrix_q (three behaviour tests that fail
with the fix reverted, two guards) and pdfcraft-automation
it::redact_text_after_q (end to end, fails at redact_apply when reverted).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
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.
/ID is SHA-256 of the seed under the label id, not an unkeyed DefaultHasher digest. The salts test is a characterization; failing closed when randomness is missing stays the regression guard.
Co-authored-by: jonathanwxh-cell <jonathanwxh-cell@users.noreply.github.com>
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.
* feat(ui): menus from craft-menu, native on macOS
One menu definition (crates/ui-egui/src/menus.rs) built from the command
registry drives the native macOS menu bar (craft-menu's muda backend) and
an in-window egui bar on Windows, Linux and the web, which takes the place
of the "Menu" button at the start of the top bar.
- File, Edit, View, Sign, Window and Help, with separators and submenus.
Edit gains Cut, Paste, Delete and Select All (they act as their keys
do) and a Pages submenu; View gains a Tools submenu built from the All
tools groups; Sign holds Fill & Sign and the certificate commands;
Window lists the open documents.
- Toggles are check items and the page layouts, side panels and themes
radio items, with their state from the app.
- File > Open Recent lists the recent files (file.open_recent with an
index).
- A menu click and its shortcut run the same dispatch, including the
form-field deferral (#166) and macOS Cmd+W closing the window (#869).
Dialogs and the palette grey the menus through craft-menu's gate.
- Quit goes through craft-quit, so the unsaved-changes prompt runs.
- craft-ui, craft-quit, craft-menu and craft-keymap pinned to
storytold/craft-libs 70ade1fb.
Menu state and dispatch follow #2610 by @hajdukste; the menu tree and the
view and panel items follow #3870 by @RivanJarjes.
* test(ui): the menu model, native dispatch and the in-window bar
- Unit tests for the menu definition: every registry menu command is
listed once with its registry shortcut; check and radio items follow
the app; a dialog greys document commands and drops their clicks; the
recent files and open documents are listed once each; a native menu
click (through a fake craft-menu backend) runs its command once.
- The kittests that opened the old "Menu" button use the menu bar, and
the ones that look up a label the bar's titles share (Edit, File,
Sign) skip the bar.
- The in-window bar takes its titles' width, so the mode tabs, search
and buttons keep their place in the top bar.
- Edit menu clicks that stand for keys (Copy, Cut, Delete, Select All)
reach this frame's input from `logic`, where test hosts see them too.
* test(ui): the language switch test opens File in the menu bar
Translated titles and rows carry their mnemonic ("ファイル(F)", "開く(O)…").
* feat(ui): the menu bars run Quit themselves, the bar shrinks to its titles, and AppKit's window list stays off
craft-libs main edc41f6 (craft-libs#354): MenuBarUi runs Quit and Minimize, shrink_to_fit sizes the in-window bar, Key::parse reads the registry's arrow and minus glyphs, and mac::install_with(.., window_list(false)) keeps the Window menu to PdfCraft's own document list.
* fix(ui): the menu command filter is an if, for clippy
* test(ui): drop a needless borrow in the edit-tab helper
* test(ui): two tests follow the menu bar
The tests were wrong, not the app. The Preferences language test clicked the old Menu button; it opens Edit in the menu bar and its Preferences row. The prepare Actions test counted the Edit labels: the narrower menu bar leaves room for the Edit tab, so the rows' Edit buttons come third and fourth.
aiongg
KenM76andClaude Opus 5.5
alehel
Dylan M. Taylor
Combiler01
aiongg
RiceDee
jonathanwxh-cellandjonathanwxh-cell
songzhihui
skylar