Adds .coderabbit.yaml so CodeRabbit no longer reviews or comments on PRs opened by dependabot[bot].
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The page's Escape handler runs in logic(), before the UI is drawn, and
ignored open popups, so one Escape closed the main menu and also cleared
the text selection. It now leaves Escape to an open popup, as
combine_ui.rs already does for its keys; the next Escape clears the
selection as before.
Any value in a PDF may be written as an indirect reference, the tagged
flag included: `/MarkInfo << /Marked 9 0 R >>` with object 9 holding
`true` is valid, and veraPDF's corpus has pass files that write it that
way. Both readers of the flag tested the reference itself, so such a
document was reported as untagged:
doc_info "tagged": false
Accessibility Checker "The document isn't marked as tagged
(MarkInfo Marked)"
Both now resolve the value first. On a pair of otherwise identical
tagged pages, one with `/Marked true` and one with `/Marked 8 0 R`:
before direct: tagged true indirect: tagged false
after direct: tagged true indirect: tagged true
and the checker reports the finding for neither.
A document with no flag at all still fails the rule, which the test
asserts alongside, so this does not turn the rule into one that always
passes.
Fixes#3671.
A glyph narrower than a twentieth of its height was matched as a fake-bold
redraw by a fifth of its height, so in OCR text layers squeezed to 20 Tz or
less the second l of "Hallo", and at 10 and 5 Tz the tt, ss, mm and ff and
letters repeated two or three places on, were dropped. Every glyph with a
width is now matched within half of it; only zero-width marks keep the
height-based distance.
Redaction removed annotations and form fields under a mark from the pages
but left the structure tree's /OBJR references to them, so a full rewrite of
a tagged PDF kept the comment's /Contents and the field's /V. apply now
drops references to every annotation no page lists afterwards (widgets of a
removed field on other pages included), as Sanitize does since #2532, and
fails closed with RedactError::Tags when an element can't be edited.
A form past the pass's depth limit is removed rather than walked. That
is the fail-safe choice for a redaction -- marked content inside a form
we cannot read would otherwise survive -- but it also removes whatever
else that form drew, marked or not. At a limit of 12, a page with a
13-deep chain lost the text of its innermost form with nothing in it
marked.
Measured on a page that draws HEAD, a chain of forms whose innermost
draws DEEP, then TAIL, with only HEAD marked:
chain before after (12) after (50)
1 HEAD DEEP TAIL DEEP TAIL DEEP TAIL
12 HEAD DEEP TAIL DEEP TAIL DEEP TAIL
13 HEAD DEEP TAIL TAIL DEEP TAIL
14 HEAD DEEP TAIL TAIL DEEP TAIL
50 HEAD DEEP TAIL TAIL DEEP TAIL
51 HEAD TAIL TAIL TAIL
The limit is now 50, which is what the renderer follows
(MAX_NESTED_INTERPRETATION_DEPTH) and what Edit text's reader follows
(text::MAX_FORM_DEPTH). So anything a reader can see, this pass can
walk. The last row is why 50 and not more: at 51 the renderer does not
draw DEEP either, so removing that form costs nothing visible and the
fail-safe still holds.
Fixes#3645's data loss. The other half of that report -- that nothing
tells the user when a form is removed -- is untouched: Report.forms_removed
is counted but the engine's edit pipeline does not carry it out, and the
one channel that reaches the result (doc.edit_notices) is typed
TextNotice, for text that could not be drawn. Widening that type or
adding a channel is a design choice for the maintainers rather than
something to slip into this fix.
`read_inner` now reads `-+280` and `++280` as well as `--280`, but
`Number::skip` consumed one sign and then required a digit, a dot or a
further `-`. So a skip failed where a read succeeded, and `ReaderExt::skip`
puts the reader back where it started -- `Object::skip` would leave the
number in place rather than step over it. `--280` was already covered,
by the `b'-'` arm.
One more sign is consumed, and the six sign forms are asserted skippable
to the end of the token. Without this the test says `-+280: not skipped`.
A third sign is still read and skipped differently (`---280` reads as 0
and skips whole), which was already so before this branch and is left
alone.
Found in review of #3630.
UniJIS-UCS2-HW-H maps code 0x0020 to CID 231 / U+2002. The OpenType
substitute for a non-embedded Japanese CID font lacks that glyph, so
.notdef boxes were drawn. Type0Font::map_via_unicode now falls back to
the substitute's ordinary-space glyph for explicit spacing characters
its charmap lacks. Native and variation-selector glyphs keep priority;
PDF advances and Unicode text are unchanged.
Fixes#3601.
Co-Authored-By: Claude <noreply@anthropic.com>
The upstream merge brought in this new tl! literal; the parallel
session's force-push had reverted the earlier translation. The
Vietnamese catalog already carries it.
iText's indirectPrev.pdf writes /Prev 6 0 R, and object 6, listed in the
same update, holds 470, the offset of the first section. Both readers took
the object number as the offset, so cos found no section at 6, rebuilt the
file from object headers and lost its revision list, and hayro's chain
stopped there.
When /Prev is a reference, the sections read so far (cos) or the section's
own entries (hayro, which now reads them before following /Prev) are asked
for that object first. If it holds a non-negative integer, that is the
offset; otherwise the object number still is, as the tiff2pdf files need.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NH3itd85jPuM6wNjgcGfEH
The cos reader learnt this in the previous commit, but the viewer and
the save's reopen check count pages with hayro, which still stopped at
the reference-valued /Prev: a four-page file showed one page, and the
correctly written full save was refused as a page-count change.
The JHOVE PDF-HUL-157 files (tiff2pdf output) end their first trailer with
`/Prev 297298 0 R`: the offset written as a reference. The chain reader took
/Prev as an integer only, so the chain stopped after the first section without
a word, and every object of the earlier sections (here pages 2-4 and their
images) read as null. The document showed one page where Poppler and MuPDF
show four, and a full save wrote the missing kids as null, so pages 2-4 were
unreadable afterwards ("cycle in page tree", 1x1 renders).
A reference-valued /Prev is now read as the offset it names, with a repair-log
note; any other non-offset value is noted and ends the chain as before.
Regression test: document::tests::a_prev_written_as_a_reference_still_reaches_the_earlier_sections.
Verified on JA3-1998-PDF.pdf: four pages read, and after a Subject edit and a
full save Poppler renders all four pages without a warning (before: "Kid
object (page 2) is not an indirect reference (null)").
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011K1peyrh5MdZ6ttHkVq8Gh
Review on #3070: the gap between pages isn't one colour on every platform;
on ubuntu CI the pixel at x = 416 was one level off the fixed sample taken
40 px from the page's right edge. The test now takes a screenshot of the
same pages before Edit text is on (no paragraph outline), checks that the
pages stay where they were, and compares every gap pixel with the same
pixel there. Removing either clip still fails it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R3niW7kVeT8mi7TpWc8eAJ
The control channel's accepting thread dropped failed accepts with
incoming().flatten() and asked again at once. When accepting keeps
failing, for example while the process has no file descriptors left,
that loop keeps a core busy until it recovers.
Wait 100 ms after a failed accept, as the single-instance listener
already does. The loop goes through a small helper so the wait can be
tested without running out of file descriptors.
A pre-publish review caught both comment errors, and Apple's own documentation settles the
rest of it:
- installed_faces_switched_off said "both loader tests". It now guards three sites — two
loader tests plus the macOS oracle — ever since 21dc64e added the third call without
touching this sentence.
- MACOS_FONT_DIRS claimed the Telugu, Sinhala and Tamil lists "still name one folder
each". They do not: Telugu names /System/Library/Fonts, Supplemental/ and /Library/Fonts
(four paths), Tamil three, Sinhala two. The accurate statement is that no family in
those lists is looked up in both system folders, which is the property Devanagari now
has and they do not. Their first choices all exist on macOS 26.6, verified again here.
- The oracle's doc comment now records the authority for treating listed faces as optional:
Apple's "Fonts included with macOS Tahoe" page (support.apple.com/122869) is titled
"Installed or downloadable fonts" and states that most install automatically while others
download via Font Book — without marking which entries are which. Absence of a face is
therefore expected on some Macs, which is exactly what the reported-not-failed behaviour
accommodates.
Comment-only change: fmt --all clean, clippy -D warnings quiet, system_fonts 13 passed with
and without PDFCRAFT_SYSTEM_FONTS=0.
A number written with a doubled sign was read by the renderer's lexer as
two numbers. `--280` set the sign, found no digit before the second
`-`, and returned 0, leaving `-280` to be read next: a `cm` carrying it
got seven operands, kept the last six, and the matrix `0 0 1 0 -280 10`
hid everything drawn under it. The page rendered blank while text
extraction still reported the text, because the glyphs were there and
only the matrix was wrong.
Measured on the report's own file, at 72 dpi, counting pixels darker
than mid-grey:
double_minus.pdf before: 0 dark px (blank) after: 581, leftmost at x=121
control.pdf (-280) 581, leftmost at x=121 -- unchanged
so the two files now render identically, which is what the report asks
for and what MuPDF does.
One extra sign is absorbed and the value is negative if either sign was
a minus, matching the COS lexer since #3299 (`--280` and `+-280` are
both -280). `Number::skip` already consumed the whole token, so read and
skip had disagreed about where the number ended.
Fixes#3565. #3299 fixed the same input in the COS lexer only.
Found while testing crates/forms/src/af.rs:166 (Parser::string)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A content stream that uses l, c, v, y or h before any m or re has no
subpath to extend. The edit-side image scan (crates/edit/src/images.rs)
handed the operators straight to BezPath's line_to/curve_to/close_path,
which panic on an empty path by contract, so object_list, page_images,
image_hit and the Office export's image walk all crashed on such a page,
while the renderer, text extraction, MuPDF and pdftotext skip the
malformed segment and render the rest.
The scan now skips the segment when the path has no elements, mirroring
the v arm's existing guard and kurbo's own condition (debug_assert on
!is_empty). A path started with m or re extends and closes exactly as
before. A clip set by a stray segment (W n on an empty path) takes a
zero bounding box, which kurbo defines as Rect::default, not a panic.
Regression test: each of the five segment operators before any m, then
a well-formed m l h and a re W n clip, all before an image Do - the
image is still listed in every case.
Verified against kurbo 0.13.1's source (line_to/curve_to/close_path
debug_assert on empty; bounding_box unwrap_or_default) and the issue's
repro; no Rust toolchain on this machine, so cargo test was not run
here - saying so plainly for the reviewer.
Co-authored-by: rahul05ranjan <11793455+rahul05ranjan@users.noreply.github.com>
Round-6 review caught that this branch rejected is_file() for one path and kept using it
forty lines above. The family loop filtered candidates with is_file(), which follows symlinks,
so an entry that exists but no longer resolves was classified "not installed" and skipped —
exactly the defect this branch fixes elsewhere.
Now both blocks share one rule: presence via symlink_metadata, then a hard requirement that
the entry resolves. Absence is still tolerated and reported; a broken entry fails loudly with
the family named, because that is the failure we are trying to catch rather than a machine
difference. Checked against this Mac first: no family or last-resort path is present-but-dangling
here, so the stricter rule cannot produce a spurious red on current macOS.
Also corrected two stale comments — the tripwire test is separate from the layout test *below*
it, and the oracle's doc comment now states the exception the PR description already does: a Mac
where nothing in the list covers Devanagari fails, since such a machine cannot validate anything.
Verified solo on macOS 26.6 (Apple M5 Max), no concurrent writers this time: fmt --all clean;
clippy -D warnings all-targets quiet; system_fonts 13 passed with and without
PDFCRAFT_SYSTEM_FONTS=0; whole crate 1341 passed / 0 failed / 5 ignored; xtask layers (37 crates)
and assets (272/6/22). Mutation evidence for the change, via font folders redirected to /tmp so
system paths were untouched: with a dangling DevanagariMT.ttc in the system folder the current
code fails at "exists but does not resolve", while reverting to is_file() filtering makes the
identical defect pass silently. Re-ran the pinned regressions too: cap raised to 512 MiB,
MAX_FACES cut to 1, probe swapped to Arabic alef, last_resort derived from first(), misspelling
restored — all red.
Review on #2994: fill rectangles and the clip were kept as their page-space
bounding boxes, so a rectangle turned or sheared by the CTM could pass as
covering the page while leaving its corners out, and a following fill became
Word's page colour. Each rectangle is now kept as its four page-space
corners, the clip as the rectangles it intersects, and the crop box counts as
covered when its corners lie inside each.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gv2WwdgjmBz33GWkwgNn3Q
Review follow-ups on #2994: under even-odd any second rectangle, under nonzero
one wound the other way, can leave a hole the Word page colour would cover.
The parity note says the page colour hasn't been opened in Word yet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Gv2WwdgjmBz33GWkwgNn3Q
A page coloured with Edit a PDF > Background exported to Word as a
white page: export pages carried text and images only, and the Word
section has no page colour.
- pdfcraft-edit `page_background`: the colour of the first thing a
page paints, when that is an opaque fill (no soft mask, Normal blend)
in a plain gray, RGB or CMYK colour, of a path with a rectangle
covering the visible page, not clipped smaller; `None` otherwise.
- `export::Page::background` carries it; the Word writer sets it as
the document background (`w:background`, plus the
`w:displayBackgroundShape` setting Word needs to show it) when every
page shares one non-white colour. Word has one background per
document, so differing colours are left out.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RUNQSPVXx3dDBabRZHAnjz
The root's MediaBox and the page's own both have four numbers, so the
length check passed even if the page lost its own value. Compare the
values instead.
Follow-up to review of this branch, no production change.
The oracle now asserts the list still ends at Arial Unicode before checking it. Without
that, deriving the path from list.first() instead of last() stayed green on this machine and
printed "not installed" — the check disappeared because /System/Library/Fonts/DevanagariMT.ttc
is absent here. Deriving the path from the list is still better than repeating a literal, but
only if something verifies it points where the test thinks.
The three retune tripwires (MAX_BYTES, DEVANAGARI_PROBE, MAX_FACES) move into their own test,
so the layout test stays about Apple's directory layout and these are labelled for what they
are: constants nothing else pins, each confirmed to be the only guard by deleting it and seeing
the matching regression go green again. Comments corrected accordingly, including not claiming
Apple moved a target when a user could equally have removed it.
Verified on macOS 26.6 (Apple M5 Max): fmt --all clean; clippy -D warnings all-targets quiet;
system_fonts 13 passed with and without PDFCRAFT_SYSTEM_FONTS=0; whole crate 1341 passed /
0 failed / 5 ignored; xtask layers (37 crates) and assets (272/6/22). Mutations re-run at this
commit: folder-major expansion, folder-order swap, typo restore, loader reversal, cap raised to
512 MiB, probe swapped to Arabic alef and MAX_FACES cut to 1 are all red; deleting the
PDFCRAFT_SYSTEM_FONTS=0 early return leaves all 1341 green, which is stated rather than hidden.
Review on #3239: a name that only numbers the glyph (C39, c251) says
nothing about the character. Reading it as the code's StandardEncoding
character invents text wherever the font's /Encoding puts the glyph
elsewhere: with /C1 at 233 it extracted O-slash for a glyph drawn as
e-acute. numbered_glyph_name and the fallback are removed; the AGL
specification's full mapping stays.
The test puts one glyph per line: the test font has none of these glyphs,
so they have no width, and on one line a later 'fi' sat on the first and
was dropped as its fake-bold copy once the guessed glyphs between them
were gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R3niW7kVeT8mi7TpWc8eAJ
annot::page_refs, the forms page_refs and organize's walk queued every
/Kids entry before the seen check, and organize cloned the inherited
attributes, Resources included, for each queued entry. A page tree whose
/Kids lists the same child many times, or whose nodes share one /Kids
array, held all of those entries at once before they were dropped as
already seen.
Each walk is now a small iterator with one cursor per open /Kids array,
the way pdfcraft_model::pages has walked since #1926. organize carries
inherited attributes as the nodes that set them and copies them only for
the pages it returns. Page order, the pages found, the inherited values
and the million-node cap are unchanged.
`cargo xtask assets` pins a SHA-256 for every catalog, so editing `es.tsv` left its
ATTRIBUTION.toml entry stale and `assets::tests::the_real_manifest_passes` failed on both
runners. Re-verified the file's provenance, updated the hash, recorded that the coverage
additions are AI-assisted and not separately native-reviewed -- as #2510 did for `lt` and
`vi` -- and regenerated ATTRIBUTION.md.
Review notes on docs/localization-parity.md:
- Lithuanian's `2,585 entries` was measured on 2026-10-13 and read as if `lt` were behind.
Re-measured today it covers the whole 2,674-key union, so it is restated like `es` and `vi`.
- *How this was measured* now says outright that the union is a moving target: every change
that adds a string widens it, a count only compares with others of the same date, and a
catalog at 100% falls behind without losing a translation. Earlier revisions quote the
union of their own date, not this one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Brandon ThomasandClaude Opus 5.5
Brandon ThomasandClaude Opus 5.5
Dylan M. Taylor
Hazel Granados
Hamza
Combiler
Jayesh-Prajapati9
NetterSilverandClaude Haiku 5.5
Eric Kaden
Ozt-y
jonathanwxh-cell
wstock
jpeskovandClaude
Ahmad Mujahid
sanches
mtlcl410andClaude Opus 5.5
oracola91
Nick Nyssen
Rahul Ranjan
Fernando Areán MagánandClaude Opus 5