Recognize text (one document) and Recognize text in multiple files ran
their worker unguarded. A panic in the recognizer (third-party inference)
or a worker that died holding the progress lock left the run in place: the
progress notice stayed, and every later run was refused with "Text
recognition is already running" until restart.
- Both workers run inside `pdfcraft_engine::guard`; a panic becomes the
run's error ("Recognize text failed: …", in the UI's language).
- `poll_ocr` treats a poisoned progress lock as a failure: it clears the
run or batch and says so.
The batch's loop moved unchanged into `recognize_files` so it can run
inside the guard. A thread that can't be spawned is #1871's (#1819), and
Export and the Action Wizard are #4043's; this leaves both alone.
Tests (crates/ui-egui/src/ocr_ui.rs): a panicking recognizer ends with
the error; a page run and a batch whose worker died holding the lock are
cleared with a notice. Both fail without the change. The OCR integration
tests pass with the real models (PDFCRAFT_MODELS).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
Review follow-up (CodeRabbit on #3488): a form an earlier PdfCraft made
should work in Acrobat once it has been filled here too, not only once a
field is added or edited. set_value now runs the same conversion (shared
with ensure_form through inline_fonts_as_objects and store_form_fonts);
it adds nothing, only changes where the existing fonts are stored.
Not in a form a signature covers (a signature field with /V): there the
file stays as the signer saw it apart from the value. PdfCraft's own
change check counts a /DR change after a form-fill certification as form
fill, but another validator may not.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A text field PdfCraft added showed its typed text in Acrobat only while
the field had focus: as soon as the user clicked elsewhere the text
vanished (it was still stored, and printed). PDF-XChange Editor and
PDFgear were fine, and the same field made by MuPDF was fine in Acrobat.
Bisected in Acrobat with one-change variants of the same file: only the
variants whose /DR fonts are objects (or that have no /DR) keep the text.
The appearance stream's own fonts, /P, the appearance layout and /DA 0
made no difference. PdfCraft wrote Helv, TiRo and Cour inline in /DR.
ensure_form now adds them as objects, and turns fonts an earlier save
wrote inline into objects too (same dictionaries). An indirect /DR or
/Font stays the object it is. The XFA-to-AcroForm writer does the same.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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).
Ctrl+Z is left to a focused text field, so in the paragraph editor it
went to the box's own Undo history. That history still held the
paragraph's text from before the last formatting change, so Ctrl+Z put
it back into a box laid out for the page after the change, a layout
the page never had, and the document kept the change. The box shared
its id across paragraphs too, so it could put back another paragraph's
text.
The history of the paragraph editor and the added-text box now starts
at what the page has. Undo and Redo keep the keys only while the box
holds typing the page doesn't have; then they reach the document. An
open box is applied (as clicking away applies it) and closed before an
Undo or Redo step, so it never shows a state the document has left;
text it can't apply keeps it open and stops the step.
fix(xfdf, sign, preflight, engine, forms, measure, annot): bound repeated work in form exchange, preflight and export, and check what imports and time stamps claim
Review on #2957, point 1. Both entry points already trim the whole name
before splitting it, and a space beside a period stays in its part,
which matches black-box observation of Acrobat and ISO 32000-2 12.7.4.2
(only a period is barred from a partial name). The test pins that down;
three mutants (no trim in add_field, no trim in set_props, untrimmed
empty-part check) each fail it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
main now renames a field in the calculations that read it. After rebasing,
that runs for a dotted name too, which moves the field under new parents: the
sum and the script that read `a` read `Group.a`, and still compute after a
save and reopen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review on #2957: own_inherited wrote what the field inherits onto it before
check_place could refuse the move, so a refused move still changed the field.
What it inherits is now read first, counted as its own by the check, and
written only once the move is allowed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review on #2957: set_props took the field out of the tree before attach
checked the destination, so a refused move (a parent holding /MaxLen, say)
left it out of /Fields for a direct caller of the forms API. The read-only
check is now its own function, run before the field is detached.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review on #2957. The field list holds only terminal fields, so a parent
left empty by a move wasn't seen and a second field of its name could be
made beside it, by adding or by renaming. And a new field joining a parent
that holds /V, /DV or /MaxLen inherited them, with no neutral value of its
own to turn them off: such a parent now takes no field that doesn't hold
its own.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A field's own (partial) name can't contain a period (ISO 32000-2
§12.7.4.2), so Prepare a form refused MASTER.first. Acrobat reads such a
name as a full name: the field `first` under a parent field `MASTER`.
- add_field: a dotted name makes or joins the parent fields it names.
- set_props: a dotted name is the full name and moves the field there,
copying what it inherited onto it first; a plain name still renames
the field within its parent. Either way the new full name may not be
taken by, or hold or sit inside, another field.
- A field joining an existing parent doesn't take its Ff or Q.
- Field Properties and the Prepare a form name tags show the full name
instead of the last part.
- Names are capped at 32 parts; empty parts are refused.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every packaging script runs under bash, so [[ ]] is available. Name the positional
parameters of sha256, render and has, end env.sh's functions with an explicit return
(bare, so the exit status is unchanged), and give the build-label case a default arm.
vendor/ is third-party code kept close to upstream (vendor/README.md), so SonarCloud's
186 findings there are not ours to restyle. MD5 in crates/crypt is what ISO 32000's
standard security handler mandates, and RIPEMD-160 in crates/sign is a digest existing
signatures can name; both S4790 findings are scoped to those two files.
30 x 42 in is `na_wide-format_30x42in` in PWG 5101.1-2023 and the IANA
IPP registry (checked against both). `na_arch-e1_30x42in` was asked for
on the IPP list in 2021 but never registered. CUPS maps the new name to
the PPD's 30 x 42 in size (cupsfilter, synthetic PPD), and the paper
test pins it and fails on the old name.
Doc comments for bad, printers and two paper tests, for the review's
docstring check.
Review: storytold/pdfcraft#4161 (CodeRabbit).
ARCH A-E went out as arch_a_9x12in .. arch_e_36x48in; PWG 5101.1 names
them na_arch-a_9x12in .. na_arch-e_36x48in (ARCH E1's IANA-registered
na_arch-e1_30x42in already had the prefix). CUPS parses either from the
dimensions, which is why the cupsfilter check passed, but a driverless
printer may accept only the names it advertises. Re-checked the corrected
names with cupsfilter against the synthetic PPD.
The paper test now pins every size's exact name, and fails on the old
spelling. Doc comments for doc_print and PrintDraft::job.
Review: storytold/pdfcraft#4161 (CodeRabbit).
A CUPS job that names no paper gets the queue's PPD default (A4 on the
reporter's Xerox queue), whatever the sheets were laid out on. Two gaps
remained after #1583:
- cups_media had no name for 13 of the 21 PAPERS sizes (A6, ARCH A-E1,
ANSI C-E, A0-A2), so the Print dialog sent no media for them. They now
use PWG 5101.1 names (the IANA-registered na_arch-e1_30x42in for ARCH
E1), which carry their dimensions: CUPS feeds the driver's size of those
dimensions whatever the driver calls it, and driverless IPP printers use
them natively. Checked with cupsfilter against a synthetic PPD whose
sizes use vendor keywords (ARCHD, AnsiD, A0...): each name produced its
size's bounding box. The 8 sizes that already worked keep their PPD
keywords.
- doc_print to a printer (CLI run, MCP) sent no paper at all. It now
resolves the paper to its PAPERS index and sends the same media option
as the dialog, after the driver options. The job is built in spool_job
so it can be tested without printing.
print::media_option is the one place both get the option from. Both new
tests were seen failing without the fix. The macOS tray half of #3752
(Auto Select instead of the PPD's default tray) is a craft-print change.
mmmaarian03-cryptoandClaude Opus 5.5
Combiler01
RiceDee
mtlcl410andClaude Opus 5.5
Eric Kaden
Marco Arnulfo
Dylan M. Taylor
songzhihui
Juan Jurado
Brandon ThomasandClaude Opus 5.5
aiongg
SBaksa