kurbo 0.13.1's stroker can give a cubic that is nearly a line (all control points within a
rounding error of its chord) a NaN join, and vello_common's `flatten::fill` drops any path
containing NaN, so the whole outline vanished. An Illustrator outline ending in
`73.763 -0.536 l 73.764 -0.536 73.764 -0.536 73.764 -0.536 c` did (#4907). kurbo tracks the
bug class in linebender/kurbo#617 and #519; #610 is unreleased.
Vendored vello_common patch (2): when the expanded stroke is not finite, `flatten::stroke`
strokes the path again with every quadratic or cubic whose control points lie within the
tolerance of its chord replaced by a line, one element out per element in. A finite outline
is unchanged, and a path with non-finite input is still dropped. `stroke` and
`StripGenerator::generate_stroked_path` take a `Clone` path; vello_cpu's callers pass
`&BezPath` and a copied slice iterator.
Tests: `flatten::tests::a_tiny_degenerate_cubic_does_not_drop_the_stroke` and the render
crate's `stroke_degenerate_cubic` pixel test fail with the fallback disabled;
`a_finite_outline_is_stroked_as_before` and `a_path_with_nan_is_still_dropped` are guards.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
An auto-size single-line field's size follows its height, up to about 12,500 pt for a
14,400 pt field. The editor measured the line's width by laying it out at that size,
before `field_screen_font` clamps to `MAX_SCREEN_FONT`, and egui rasterizes every glyph it
lays out: one such measurement took 1.2 s in a debug build, on every frame. The width is
now measured at no more than `MAX_SCREEN_FONT` and scaled, which is exact up to the bound
and linear above it.
`tools::forms_ui::tests::a_line_is_never_laid_out_above_the_screen_font_bound` fails with
the bound removed (laid out at 12,522 pt).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
Inside a text object q/Q save and restore Tm and Tlm too (ISO 32000-2
§9.4.1, as corrected by the PDF Association's erratum,
pdf-association/pdf-issues #368). The renderer's saved state already
holds both. The text-editing interpreter and the heading detector kept
them across Q: text after Q was listed (and, once edited, moved) where
the q ... Q block left the pen, and a word continued after Q was split
("Chap ter One"). Both saved stacks now hold the two matrices.
Tests: pdfcraft-edit and pdfcraft-a11y
tests::q_inside_a_text_object_restores_the_text_matrices. Reverting
the edit fix puts the first case at y = 600, not 700; restoring only Tm
puts the T* case at 586, not 686; reverting the a11y fix reads
"Chap ter One". Each fails its test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
Keep the print module split and reapply the /Contents space join in
imposition::decoded_contents, matching the renderer and the organize pruner.
Co-authored-by: jonathanwxh-cell <jonathanwxh-cell@users.noreply.github.com>
main deleted crates/engine/src/reexports.rs and moved its re-exports
into crates/engine/src/lib.rs; the comb_auto_text_size re-export this
branch added now sits in lib.rs. forms_ui.rs moved to
crates/ui-egui/src/tools/; the branch's hunks carried over unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
Two content conflicts, both from main splitting the files this branch edits.
crates/cos/src/document.rs: main moved Document into document/*.rs.
Keep that split. A missing /ID is still pdfcraft_crypt::file_id of the
encryption seed (document/open.rs); generated_id is gone. The regression
lives in document/tests.rs.
crates/engine/src/edit.rs: main moved EditCtx and run_edit into
edit/run.rs. Keep that split. Protect still draws its seed and default
owner password from getrandom on EditCtx and fails closed
(EditError::Protection) when the CSPRNG errors or returns all zeros.
Co-authored-by: jonathanwxh-cell <jonathanwxh-cell@users.noreply.github.com>
In Edit text & images a click inside a paragraph opens it for typing, and selecting the whole
box meant aiming for its thin frame: a press a few pixels inside put the caret in the text
instead (#2203). Esc in the inline editor now leaves the text and selects the paragraph's box,
as Acrobat does, so Esc then Delete removes it, the arrow keys nudge it and its frame drags it.
Esc still discards an unapplied draft.
The editor asks `ObjectSelection` to select the paragraph, and the next `prepare`, which has the
document's inventory, selects it after its own Escape check, so the Esc that closed the editor
cannot clear the new selection.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The only content conflict was crates/engine/src/lib.rs: main moved
EditCtx and run_edit into edit.rs, while this branch taught Protect
to draw keys and salts from getrandom and fail closed. Keep main's
module split and apply that CSPRNG behaviour on EditCtx in edit.rs.
The regression test imports EditCtx and run_edit from the edit module.
Co-authored-by: jonathanwxh-cell <jonathanwxh-cell@users.noreply.github.com>
A non-isolated knockout group starts from the backdrop under it (ISO 32000-2
§11.4.7, §11.4.8), but was drawn into a layer of its own starting transparent,
so a blend mode inside it had nothing to blend with: white with /BM /Difference
over magenta stayed white (#4886).
Entered plainly (full opacity, no soft mask, Normal, not itself a knockout
element), the group is now drawn once per blend mode its elements use. Each pass
is a knockout layer composited onto the backdrop in that mode; elements of other
modes clear what is under their shape instead of painting. The Normal pass finds
the other modes, so a group without blend modes takes one pass as before.
hayro-interpret patch 67 (Device::begin_knockout_pass / end_knockout_pass,
draw_knockout_passes), hayro patch 26 (the renderer side). Test:
pdfcraft-render it::knockout_backdrop, three cases failing with the fix
reverted, plus an isolated-group control.
Fixes#4886
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
Review on #4831 pointed out the PDF Association's erratum to ISO 32000-2
(pdf-association/pdf-issues #368): inside a text object, q/Q also save and
restore Tm and Tlm (§9.4.1, referenced from §8.4.2). Acrobat 26.2 agrees on
a synthetic PDF 2.0 page. The renderer on main already did this, so the
previous commit's hayro-interpret patch (67) was wrong: it is reverted here,
with its vendor/README row and the render tests.
The real disagreement was in the redactor's own interpreter, which kept Tm
and Tlm across Q. Find took its boxes from the renderer's text, the redactor
measured the glyphs elsewhere, and redact_apply refused on residue. Its
state stack now holds (Gs, Tm, Tlm) and Q restores all three.
Test: it::redact_text_after_q, end to end on %PDF-2.0 fixtures, three cases
(font change inside q/Q; q 100 0 Td Q; the same followed by T*). With the
redactor change reverted, each case fails on its own at redact_apply. With
only Tm restored, the T* case fails.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
Review on #4862 found two mismatches between the on-page field editor and
the field's appearance:
- Comb fields: the editor sized them as single-line text (20.87 pt for a
500 x 30 comb) while the appearance uses 4-12 pt from the cell height.
The comb test is now `Field::is_comb` and the comb size
`appearance::comb_auto_text_size`, both shared by the appearance and
`forms_ui::field_text_size`. The editor's test was looser (it ignored
Multiline and Password); it now matches the page's.
- Tall fields: `field_text_size` capped at 300 pt and the three call sites
clamped the screen font to 64. Both are gone; `field_screen_font` scales
by zoom and bounds the result at MAX_SCREEN_FONT (256 screen points) so a
glyph stays well inside the font atlas.
A non-finite comb height now gives 4 pt, as single-line auto-size does.
Test: it::forms::the_field_editor_sizes_auto_size_text_as_the_page_does.
With the comb change reverted the comb assertion fails (20.87 vs 12); with
the 300/64 caps restored the 100 pt assertion fails.
Also fixes it::forms::dragging_over_another_fields_text_focuses_it_and_selects_from_the_press,
which the previous commit broke: the name field now auto-sizes to 13.9 pt
instead of 12, so the press point 30 px in fell on "A|da"; it is now 38 px
in, inside "Ad|a" as the test intends.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9
Combiler01
KenM76andClaude Opus 5.5
Cursor Agentandjonathanwxh-cell
songzhihui
alehel
HiteshandClaude Opus 5.5
aiongg
aiongg
skylar taylor-barrick