mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-11-07 03:01:55 +00:00
ddeca878dff1ea6cc2fa55adb2db84513eecda1f
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
    
|
9f04acccef |
M10: OCR engines, confidence, preprocessing and a review workflow (#977)
* M10.20: plan Unicode text for OCR output in Type3 faces (fonts, edit) OCR output used to flatten every character beyond WinAnsi to a silent `?`. This adds the two pieces that let the OCR layers write the recognized words as they are; the OCR code that uses them follows in M10.21. pdfcraft-fonts - `TextPlan::for_words` maps each word to the standard Helvetica when WinAnsi covers it, else to Type3 fonts drawn from the craft-fonts faces (the Japanese document face first, then the rest of the build input). Characters no face has a glyph for are counted (`missing`), never dropped silently. At most 240 characters per font and 2400 per plan, so one hostile word cannot balloon. - Which face has which character is asked once per (face, character) for a plan, not once per word. - `face_has`, `craft_glyph`, `win_ansi_char`, `fits_win_ansi` are public for it. pdfcraft-edit - `add_type3_fonts` / `stamp_with_fonts` register a plan's fonts on a page under a free `PCOcr`, `PCOcr1`, ... name, build each font once and share the object with later pages. A shared face is registered under a free name on a later page that already has a font of the name it was given first, instead of replacing that page's own font. - The fonts carry real advances and a ToUnicode CMap, so extraction reads the text back. pdfcraft-redact - A test shows a hand-built Type3 text layer (the shape the OCR output writes) is redacted like any other text and the verifier passes. Tests: pdfcraft-fonts 62 passed, pdfcraft-edit 129 passed, pdfcraft-redact 33 passed; clippy -D warnings clean on the three crates. The name-reuse and the redaction tests build their fonts by hand, so they run without the craft-fonts build input; the tests that plan real faces skip without it and were not run in this commit's own check. * M12: give the hostile-XFA open test more room on a loaded machine The test opens a form whose calculate script sets a value 50 000 times, against the one-second budget of an unasked script and a five-second wall-clock bound on the open. Both sit close to what a machine running several suites at once can take, so the test can fail without anything being wrong. It now runs 20 000 iterations (the total is 19999) and allows 30 seconds, which still fails for a script that hangs or is not capped. Test-only; unrelated to the OCR work in this series, so it is a commit of its own. Tests: both hostile_xfa tests in pdfcraft-engine pass. * M10.21: pluggable OCR engines, preprocessing, review sessions and the OCR tools (ocr, engine, create, automation) Scan & OCR gets a second engine, optional raster clean-up, a review step before anything is applied, editable output and a batch mode, headlessly first: the interface for them follows in M10.22. pdfcraft-ocr - A `Recognizer` trait with two engines: the built-in ocrs (moved out of lib.rs) and the installed tesseract program, run as a fenced external process: fixed argv, allow-listed language codes, a private temp directory (mode 0700 on Unix), 120 s timeout, 64 MiB output cap, 50 000-word reading cap. A location from PDFCRAFT_TESSERACT is validated (absolute, existing, executable) and an invalid one fails closed instead of falling back to the PATH. `--list-langs` and `--version` are read from stdout or, for older versions, stderr. - Strategies: PrimaryOnly, ConfidenceWeighted (the second engine joins when the first reading's mean is under 70 or unknown) and a ROVER merge (higher confidence wins per word; against an ocrs word of unknown confidence a tesseract word wins only at 70 or more; capped at 100 M comparisons; a failing partner degrades to the primary with a note). - Preprocessing: opt-in auto-rotate, deskew, denoise and binarize on the RGBA raster, each with an exact inverse so word boxes map back to the scan. The 300 dpi normalization the steps are calibrated for runs only when a step is on: with every step off the render is read as rendered, as before. (Enlarging a 72 dpi render 4x on its own made the models read "due: €250" as "ue: ?250".) `OcrImage` is validated by construction (side and 64 MP area caps, checked before any buffer is allocated, including by the resize). - Confidence bands (High >= 90, Medium 70-89, Low < 70) drive review. pdfcraft-engine, pdfcraft-create - `OcrSettings` gains engine, strategy, the four steps, output mode, region, the skip flags and the low-confidence threshold; Automatic reads confidence weighted unless a strategy is chosen. - A recognition is a session: the document guard refuses a stale result with its reason, pages can be applied one at a time (the guard is taken again after each applied page), and applying is one undoable step. A per-language dictionary (a plain-text file: words added from any document stay on disk after it closes). - Output is searchable (an invisible layer) or a NEW editable document of visible text at the recognized boxes (`create::from_contents`); words beyond WinAnsi use the Type3 faces of M10.20 in both, with the shared plan across pages. - Engine discovery never blocks the interface: results are cached, a stale answer is shown while a background probe retries, and the models search and `--version` are cached. Batch: pages or files that already have text are skipped unless forced, and inputs sharing a file name are found up front. pdfcraft-automation - ocr_recognize (engine, strategy, steps, region, output mode), ocr_words (with a retained review handle), ocr_review_apply, ocr_dictionary, ocr_status and ocr_recognize_files. The editable `out` must be a new file inside --root and is refused for a searchable run (it used to be ignored), two batch inputs of one file name are refused before anything is read, and the batch folder is checked for existing outputs. pdfcraft-ui-egui - Only what the new API needs: the Recognize Text dialog reads with `recognizers(&settings)`. `ocr.correct` is registered with its label in every catalog; the screen itself is M10.22. Tests: pdfcraft-ocr 78 passed; pdfcraft-create passed; pdfcraft-engine and pdfcraft-automation 450 passed and 1 failed (the automation lib 17, automation.rs 157, hostile_args 2 among them); pdfcraft-ui-egui lib + ocr + control tests 391 passed; clippy -D warnings clean on the five crates. The one failure is in a test this commit does not change: recognize_text_makes_a_scanned_page_searchable fails where the models are installed (they read "quick" as "auick" at that render size); the roadmap on main already records it. The real tesseract binary ran in tesseract::tests::recognize_runs_the_installed_binary (tesseract 5.4.0, PATH). * M10.22: OCR Verify screen, the Recognize Text options and the interface catalogs (ui-egui) Scan & OCR ▸ Correct recognized text: a full-window screen where a recognition is reviewed before anything is applied, plus the dialog and batch options for the engines of M10.21. OCR Verify screen - Four panes: the page list, the source page with confidence-coloured word boxes (click to select, drag to draw a region), the recognized text, and a zoom plus word inspector. Corrections commit on Enter (an empty commit removes the word), Remove/Restore, "+ Dictionary" (a per-language file in the preferences folder, so a word added from a document stays on disk after it closes), per-word and per-page Verified, F8 / Shift+F8 walk the low-confidence words, Ctrl+T marks the page reviewed, Ctrl+Tab moves the pane focus, and review edits undo within the panel. - Re-OCR of the whole page or a drawn region. A region re-read moves the review marks of the words it keeps to their new positions and selects the first new word; a whole-page re-read clears that page's marks (and the undo brings them back). The region outline is scaled onto the pane, not mapped through user space again, so it is right on rotated and cropped pages. - Accept / Reject per page or whole. Pages accepted one at a time each apply once (the document guard is taken again after each applied page; an edit made elsewhere in between is still refused with its reason), and Accept in searchable mode is one undoable step. Editable mode writes a NEW `<name>_ocr.pdf` through a save dialog and never the source. A real Cancel keeps the pages already read. - The engine and strategy menus disable a choice that cannot run and say why; the check never waits on a process (a background probe fills a cache), and choosing Automatic moves "Primary only" to Confidence weighted. Recognize Text dialog and batch - Engine, strategy, the four clean-up steps and the skip flags are remembered with the other choices (a saved Automatic without a strategy reads confidence weighted). The batch refuses two inputs of one file name and existing outputs before reading anything, notes low-confidence pages at the settings' threshold, and its toast has a Cancel (the file in flight finishes). Catalogs and attribution - The 90 new interface strings are in all 21 catalogs (the Lithuanian ones were written without native review, and the Bulgarian ones avoid U+045D, which the bundled monospace face lacks). ATTRIBUTION.toml carries the new hashes, a note on the Lithuanian entries and the README screenshot; ATTRIBUTION.md is regenerated. - README: a screenshot of the Verify screen, taken with `cargo xtask screenshots` from a synthetic scan (`shot --ocr-verify on`) built from allowed assets; the page reads it with the real engines. Tests: pdfcraft-ui-egui lib 373 passed (1 ignored: the Windows hinting measurement probe), tests ocr 6, control 46, fonts 9; clippy -D warnings clean on the engine, ui-egui, pdfcraft and xtask packages; `cargo xtask assets` ok. The review state machine has unit tests for every fix above; each was seen failing with its fix reverted. * M10.23: parity entries, roadmap and localization notes for the OCR workflow Records what M10.20-M10.22 ship, and what they do not. parity/acrobat-features.toml - Status changes against main: ocr.rotation-detection and ocr.deskew planned -> shipped (the opt-in steps of M10.21, with their tests); ocr.correct-recognized- text and ocr.ocr-engines planned -> partial. Other Area I entries get their evidence and notes brought up to date. - ocr.correct-recognized-text: the evidence includes the one-page-at-a-time accept and the region re-read tests; the notes say what the headless tools cover (ocr_words with a retained review, ocr_review_apply through the same stale- document guard, ocr_dictionary) and what is still UI-only (suggestions, per-word Verified marks, region re-reads). - ocr.ocr-engines stays partial rather than shipped: part of its evidence is conditional (the real-binary test runs only where tesseract is installed and skips elsewhere, and the process-level tests are Unix-only). It cites the tests that always run (location validation and the fail-closed rule, --list-langs parsing from stdout or stderr, the merge rules, the default strategy) and says which part is not proven everywhere. - `cargo xtask parity`: area I 32.7% -> 44.2% weighted (5 -> 7 shipped, 7 -> 9 partial); overall 52.8% -> 53.0% shipped and 58.2% -> 58.5% weighted. ROADMAP.md - One progress-log entry (2026-10-13, newest first) and the banner line. It says the catalogs are 21 with the Lithuanian additions not natively reviewed, that the end-to-end redaction test of the Type3 layer needs the craft-fonts build input, and that recognize_text_makes_a_scanned_page_searchable still fails where the models are installed, as main's log already records. docs/localization.md, docs/localization-parity.md - The Lithuanian entry count (2,578 -> 2,668) and the counts of the other catalogs that carry entry counts are re-measured with the 90 new entries; the Lithuanian OCR entries are marked as not natively reviewed. Checked: `cargo xtask parity` (numbers above, evidence tests exist) and `cargo xtask assets` pass on this tree. * M10.24: ocr: apply a late result only to the document it was read from The Recognize Text dialog closes on Go, so the document can be edited, or have text redacted, while a long run is still reading. The result was applied without the stale check the tools and the Verify screen use, so words read before a redaction could be written back as invisible text. The run now keeps its guard and applies through the checked path. Accept with the editable output in the Verify screen had the same gap (Exit keeps the review open): it now refuses when the document changed since the review started. Both new tests fail with their guard switched off. * M10.25: ocr: ocr_dictionary takes dictionary file names only Updating sorts, lower-cases and rewrites the file it is given, so pointed at .env or a README it would corrupt it. The tool now accepts only ocr-dictionary-<language>.txt style names, for reading as well as writing. The size-limit test used a file name the rule now refuses first, so it renamed its fixture to keep testing the size limit. The new test fails with the rule switched off. * M10.26: pt-BR: keep (s) on the word counts and say mecanismo for engine Two review fixes from a native speaker: the two word(s) lines had lost their (s), so a count of 1 read as 1 palavras, and engine was translated both as motor and mecanismo. Mecanismo is the Brazilian word for a software engine and two lines already used it, so the other six now match. * M10: fit the rebased OCR workflow to current main's structure * Fix OCR workflow issues from the review Honor the Recognize dialog's editable-output choice: its result opens in the review screen (whose Accept writes the editable document) instead of an invisible layer. Make page acceptance idempotent: a second Accept entire page never appends the OCR layer twice and keeps later corrections. Move page and region re-OCR onto a worker thread with a status line and a cancel that discards the reading. Skip the Tesseract probe for jobs that name their engines. Bound Tesseract's stderr while the child runs, not only after it exits. Surface the editable output's substitution notes in the tools' and the run's results. Also repair the OCR batch tool against the current structure: inputs are held to the read root again, and a batch whose inputs share an output name is refused before the output folder is created, compared the way the default filesystem compares names; and the editable writer test's word stays inside the fixture's pages. * Apply pre-review fixes to the OCR workflow Hold the automation OCR tools to the document's copying permission, as the other text tools are: the recognized text is left out of the results when copying is forbidden, and the paths that carry the words out of the document (the editable output, the review word list) are refused. Mark the ocr_dictionary tool as overwriting its path. Close the searchable layer's graphics state around its invisible text so the rendering mode cannot leak into later content. Read the OCR user dictionary folder from the portable data folder in portable mode, like the recovery store does. Resolve the attribution manifest's leftover conflict markers and regenerate the generated attribution. Describe the review flow, the searchable layer's Type3 fonts and the parity evidence references accurately, and drop an undeclared copy of the recovery module. * OCR: reject readings that exceed the word limit Assisted-by: OpenAI Codex * OCR: new documents go through the page tree builder main added Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * OCR: review notes and lints The editable output refuses a file created during recognition. ocr_words takes skip_text_pages and force_ocr. Automatic OCR checks the engine it will use. The stderr test stays below the kill cap, and a failed --ocr-verify shot exits with an error. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * OCR: restore the Verify screenshot attribution, follow the moved constants The merge dropped the screenshot row with the translation rows. The model filename constants live in ocrs.rs now, so the license check reads them there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Attribution: the Verify screenshot entry goes after the header comment Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Attribution: the screenshot row in the table follows the manifest order Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: eliets2 <287273517+eliets2@users.noreply.github.com> Co-authored-by: FredApps <FredApps@users.noreply.github.com> Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
6427357fcb |
Forms: date fields name months in the date language, not always English (#5303) (#5464)
* Forms: date fields name months in the date language, not always English (#5303) `AFDate_FormatEx("dd-mmm-yy")` wrote "18-Oct-26" in an Italian interface, where a localized Acrobat writes "18-ott-26". Form date formats, `util.printd` and `util.scand` now take their month and weekday names from the date language (Preferences > Date format > Language, which follows the interface language until one is picked), and still read English names typed in. The names are process-wide, so their test runs in its own binary. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: dates read back in every date language (#5303) Trying every date language showed what a field wrote not always reading back: names holding digits ("10月"), spaces ("tháng 10"), dots ("ม.ค.") or combining vowel signs (Thai, Hindi, Telugu) fell apart word by word, and Italian, Spanish, Romanian and Albanian share some short weekday and month names ("mar"). The language's names are now found whole in the text first, the longest at each place, and read as their English names; the format's order of `mmm` and `ddd` settles a shared name. Both AFDate parsing and util.scand do this, on text up to 1 KB. A test reads back every language, each name format, and hostile text. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: date names no field font can draw are drawn in English (#5303) With the names in the date language, a Russian dd-mmm-yy field drawn in Helvetica showed "18-????.-26": no /DR font held "окт." and the WinAnsi stand-in drew each letter as ?. The same held for Japanese, Chinese, Greek, Arabic, Thai and others, and for Latin names outside WinAnsi (Czech "říj"). Before, the names were English and always drew. An AFDate/AFTime field now formats its value again with English names for a widget whose fonts can't draw the localized text; a custom Format script is run again with util.printd writing English names for such a widget, and its result kept only when it draws whole. A field whose font holds the names keeps them, and scripts otherwise still print the date language. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: an English weekday before the month keeps the month (#5303) With Italian dates, "Tue 17 Mar 2026" in a "ddd d mmm yyyy" field read as no date: the language's names were found in the text, but not English ones, so "Tue" left the format's weekday unfilled and "Mar", which Italian shares between Tuesday and March, was taken as the weekday. Both AFDate parsing and util.scand lost the month, and Spanish, Romanian and Albanian ("mar") did the same. English names are now found too and fill their field of the format as localized ones do. A test reads English and mixed weekdays before the month in those languages. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: an English date run is drawn even when it prints the value (#5303) A Helvetica field storing "18-Oct-26" whose Format script prints it again as dd-mmm-yy still showed "18-???.-26" in Russian. The English run printed "18-Oct-26", but it was dropped for equalling the stored value, which was how a failed run was told apart: a failing script handed back the value unchanged. The English run now says whether it ran (`None` when the script failed or the runner can't write English dates), and what it made is drawn whenever it draws whole. A test reprints the stored value under Russian, and checks that a failing script keeps its text and is reported undrawn. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: a short weekday typed without its dot is the weekday (#5303) With French dates, "mar 6 janv 2026" in a "ddd d mmm yyyy" field read as no date through util.scand, and "mar 06/01/2026" in "ddd dd/mm/yyyy" through AFDate too. French writes Tuesday as "mar.", which a name search only found with its dot; since English names are found as well, the English "Mar" (March) was the only name of that length, so the weekday became a month. Romanian "mar" did the same. A short name ending in a dot is now also found typed without it, as the same kind of name, so the format's order of name fields decides between it and an equal name of the other kind. Both copies of the name search change. A test reads French and Romanian weekdays typed without their dot. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: a shared name is the month when no weekday is typed (#5303) With Italian dates, "17 mar 2026" in a "ddd d mmm yyyy" field read as no date, nor did "mar 17, 2026" in "dddd, mmmm d, yyyy". AFDate leaves weekdays out of what it reads (they are shown, not typed), but the name search still expected the format's weekday first, so "mar", which Italian shares between Tuesday and March, filled it and left no month. Spanish and Albanian "mar" and Albanian "sht" (Saturday, September) did the same, and the keystroke check refused those dates. Where such a read finds no date, the names are now read again with no weekday expected, so the shared name is the month; a typed weekday still comes first ("mar 17 mar 2026"). util.scand reads its fields in order and needs the weekday, so it is unchanged. A test types those dates with the weekday left out. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: Turkish names typed in capitals are read (#5303) With Turkish dates, "1 MAYIS 2026" and "1 EKİM 2026" in a d mmmm yyyy field read as no date through AFDate and util.scand, and "SALI 6 OCAK 2026" through util.scand. Names were compared lower-cased, which turns I into i, not the dotless ı of "Mayıs" and "Salı", and İ into i with a combining dot above, which "Ekim" doesn't have. Names and typed text are now folded alike, the capital I and the dotted and dotless i all as i and the combining dot dropped, one piece for each char so positions in the text stay aligned: in both copies of the name search, the AFDate month reader and util.scand's name matcher. English reads as before. A test types Turkish names in capitals and English ones as a check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Forms: Greek names typed in capitals are read again (#5303) Folding names char by char turned a capital Σ into σ, so "ΙΑΝΟΥΆΡΙΟΣ" no longer matched "Ιανουάριος", whose last letter is the final ς. The fold now makes ς a σ on both sides, in the forms and JS parsers alike. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com> |
||
 KenM76andClaude Opus 5.5
|
e93e8d50ba |
fix(edit): keep a soft mask anchored when the edit is lifted over the scan (#3973)
A soft mask is placed by the CTM in force when its `gs` runs (ISO 32000-2 11.6.5.2). The paragraph lifted over the scan re-selects the graphics state after its own `cm`, so a mask selected before a translation landed translated with it and could hide the new text. A re-emitted state that carries a dictionary /SMask now records its anchor CTM and is selected there: `cm` to the anchor, `gs`, `cm` back. The test edits the same paragraph with and without a mask and requires the same ink; it fails with the re-anchoring disabled (the mask lands 100 pt right and the text vanishes). Both rewrite paths. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9 |
||
|
KenM76andClaude Opus 5.5
|
270a11e699 |
fix(edit): refuse before changing anything; cover undo, reopen, re-edit and the split case
An OCR paragraph that may go on top of the page is checked (`check_on_top`) before either rewrite path changes the document, so a page whose marked content nests too deep is refused with nothing changed. `lift_on_top` no longer checks. Tests: undo restores the hidden layer and the scan, redo, save and reopen, and a second edit of the moved text all show the edit; a phrase split from visible text in the same text object shows its edit; a refused rewrite on a too-deep page leaves the saved bytes unchanged. Each new test was seen to fail with its part of the fix reverted. Parity: the note says when the edit is drawn on top and lists what is still missing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9 |
||
|
KenM76andClaude Opus 5.5
|
cc9d95e1fb |
fix(edit): an edited OCR phrase under its scan image is drawn on top (#3973)
Some OCR tools write the invisible text layer first and the opaque page image after it. Edit text rewrote such a phrase in the text's place, so the cover and the new visible text were painted under the scan: the edit was saved (text extraction finds it) but nothing showed. When the rewritten paragraph was invisible and an XObject, inline image or shading is painted after its place, the cover and the new text now go on top of the page in their own q/Q (place_tagged, tagged Edited), drawn from the initial graphics state with the paragraph's CTM. Only the state the following text expects stays in place. Both rewrite paths (single style and styled rows) do this. An OCR layer drawn over its scan, the common case, is rewritten in place as before, so reading order is kept. The test builds a scan whose OCR word comes before the image and checks the cover and new text show, for one line and for a typed line break. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SqmHYx8FiWM5PcsoiErgp9 |
||
 aiongg
|
467c8556ec |
fix(engine): encode each image once for Office export
Office export encoded and kept a separate copy of an image for every place a page drew it, so a short content stream repeating Do on one large image multiplied it into gigabytes before the writers' limits applied. Each image object is now encoded once and its bytes shared (pdfcraft_export::Image holds an Arc<[u8]>), distinct pictures share a 512 MiB budget whose overflow lists the page as truncated, and RTF, which leaves pictures out, prepares none. |
||
 aiongg
|
9526363152 |
Build each crate's integration tests as one binary (#4087)
* 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. |
||
  Ahmad MuandBrandon Thomas
|
38999b3e90 |
fix(edit): isolate added marks from unfinished marked content (#3279)
Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
5cce1b247f |
M10: edit OCR text on scanned pages so the change shows (#1397)
* M10: edit OCR text on scanned pages so the change shows Editing a recognised word on a scan rewrote it as invisible OCR text, so the page still showed the old word, and the whole OCR layer grouped into one paragraph that rewrapped when one word changed. - An edited invisible paragraph is drawn visibly, over a cover in the paper colour sampled around it, in the scan's sampled ink colour (or the chosen colour). - OCR words group into phrases: a table cell or a tab stop splits them and each scanned line stays apart; a phrase grows rightwards. - Styled rewrites measure with the text matrix's horizontal scale, so stretched OCR words keep their widths instead of overlapping. - The inline editor covers the scanned word and grows like the result. * M10: size OCR text from each word's letters A word box from recognition is tight around the ink, but the text layer assumed every box spans Helvetica's ascender-descender height. A capitals-only word such as "DT" spans only the cap height, so its text was set about 23% too small and its baseline floated up; editing it then drew the new word visibly smaller than the scanned one. The em and baseline now come from the word's letters: cap height or x-height on top, descender or baseline at the bottom. On a real scanned form, a rewritten "DT" -> "DSI" now matches the scanned word's height and baseline. The engine OCR-edit tests build their words the way a scan would box them. * Edit OCR text: sample colours only for invisible blocks, from the current bytes Session::apply looked up every edited block with a fresh text_blocks pass and re-serialized the whole document to render the sampling tile. Text blocks are now cached per page on the editor (keyed on the unmodified document's source identity, so any edit, undo or save invalidates them), visible blocks skip sampling entirely, and the tile renders from the document's current bytes. Adds a visible stretched-text regression test and documents that editing any invisible text makes it visible over a painted cover. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Edit OCR text: name the cached text-blocks tuple (clippy), rustfmt Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Brandon Thomas <echelon@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
  
|
6d843a8e8b |
Preserve source fonts in text editing and resize clipped artwork (#1116)
* M0: remove upstream trademark artwork from contributor fork
Use the existing document icon and a plain project label. Remove trademark
asset entries and regenerate attribution as required for modified forks.
Co-authored-by: OpenAI Codex <codex@openai.com>
* M7: group compatible PDF words and hide source text during editing
Join compatible words across text objects and subset-font spaces, recognize
component colours, and reuse subset fonts with numeric space positioning.
Render a read-only background with the selected glyphs removed while the
inline editor is open. Keep one frame and source line breaks, and reset
the layout width when switching paragraphs. Expose the same preview through page_render.
Add synthetic extraction, save/reopen, preview and UI regressions. Record
the remaining mixed-style paragraph and installed-font limitations.
Co-authored-by: OpenAI Codex <codex@openai.com>
* M7: preserve rich PDF regions and preview text edits in place
Group mixed source runs into complete visual regions, retain run styles and source encodings, and use validated embedded source faces in the inline editor. Preserve source baselines and show a single live frame as text grows or shrinks, backed by a read-only draft geometry tool.
Validation: strict workspace Clippy, workspace tests, all 30 WASM crates, asset and parity gates, licensed synthetic edit/save/reopen and desktop checks, and an opt-in four-page private-document regression.
Co-authored-by: OpenAI Codex <codex@openai.com>
* M7: keep cropped artwork from blocking text editing
Track page/path clipping separately from full image placement, use visible selection bounds, and prioritize text hit testing over overlapping artwork. Preserve fixed clips during image transformations and expose visible bounds through the headless tools.
Validation: strict workspace Clippy, workspace tests, 30 WASM crates, asset/parity gates, synthetic engine/tool/UI and native desktop checks, both private-document UI regressions, and all-page local edit/save/reopen/undo on a four-page cropped-artwork PDF.
Co-authored-by: OpenAI Codex <codex@openai.com>
* M7: resize cropped images with their clipping paths
Keep the visible frame and image pixels under the same transform. Preserve the
opposite corner and respond to diagonal, horizontal-only and vertical-only
corner drags without jumping from an off-centre grip. Refuse shared clipping
scopes that would move unrelated content.
Add synthetic engine/tool/UI regressions and opt-in private-file coverage
for 80 corner gestures and 10 grow/shrink save/reopen/undo render checks.
Co-authored-by: OpenAI Codex <codex@openai.com>
* M7: complete source font subsets and preserve clipped editing
Add explicit document fonts, CFF embedding, range formatting and bounded contextual shaping; isolate shared image clips and verify private Chinese edits on all pages.
Co-authored-by: OpenAI Codex <codex@openai.com>
* Revert "M0: remove upstream trademark artwork from contributor fork"
This reverts commit
|
||
 
|
d415749556 |
Heavy pages: cull off-tile images, cache decodes, preview backdrops, calmer queues (#1117)
* Heavy pages: cull off-tile images, cache decodes, preview backdrops, calmer queues A large CAD sheet (page 24 of the benchmark file: ~5050 pt wide, 2104 images, 9 MB of content) cost a full page interpret per tile: 4.3 s for a 1024 px tile at 1000%, 10.5 s for the whole page, and a storm of renders on every pan frame. Tiles now cost 0.6 s, the sheet is covered by a handful of large tiles, and gestures no longer queue work faster than workers finish it. - Vendored hayro patch (10): skip images whose stream-size box misses the canvas before decoding them, so a tile no longer decodes, resamples and rasterizes every image on its page. Pixel-identical; the skip regression test now covers images too. - Vendored hayro-interpret patch (23): decoded image pixels shared across renders through the interpreter cache, keyed by stream and decode target size within a 64 MiB budget. - Preview renders (hayro patch 11, RenderRequest::preview through to the device): backdrops, thumbnails, grid cells and signature-drag backgrounds skip images under 16 device px. Tiles, whole pages, print and export always draw everything. Previews may differ by those pixels; finals don't. - Viewer: zoom/pan settle holds apply only to pages whose raster proved slow (slow_pages, 500 ms), so fast pages render with no added latency; tile sides grow with zoom and page size (giant sheets need ~8 tiles, not ~28), queued center-first and keyed by exact coordinates; Edit-text outlines capped. - vendor/README.md records the new patches with their tests. Co-Authored-By: Muse Spark <noreply@meta.com> * Decoded-image cache: key every decode input, survive a poisoned lock The key was the dictionary's bytes and the target size, so two images with byte-identical dictionaries (uncompressed, one size) shared pixels, and an image drawn under a transfer function reused pixels decoded without it. DecodedImageKey now holds the dictionary's place in the document (its data follows it), its bytes and object, mask/stencil/raster output, interpolation, the target size and preview or final quality; images under a transfer function and inline images (named colour spaces, dictionaries in content streams) are not cached, and an image over the budget is never kept. A poisoned lock decodes uncached instead of panicking. Soft masks: the per-renderer cache can't carry a preview mask into a final render (documented). Regression tests for identical dictionaries, preview then final through one cache, and transfer functions. --------- Co-authored-by: Muse Spark <noreply@meta.com> Co-authored-by: Brandon Thomas <echelon@gmail.com> |
||
|
Brandon ThomasandClaude Opus 5.5
|
86ec14291c |
Fix main CI: move the rotated-field render test out of pdfcraft-forms (#591)
#516 added pdfcraft-render as a dev-dependency of pdfcraft-forms for one rendering test. Both crates are layer 3, so `cargo xtask layers` (run in CI) rejects the sideways edge and main went red. The test now lives in crates/engine/tests/form_rotation.rs, where both crates are already dependencies, and forms drops the dev-dependency. The parity evidence points at the new location. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |