Review of #4171: cacheable() shrank an oversized picture to half the cache
minus its source size, so a source of 64 MiB or more left no room, and the
cache, which counted the source bytes each entry held, refused the entry.
Such a picture (an uncompressed 5000 × 5000 BMP is 75 MB) was still decoded
on every render. A broken source of 128 MiB or more was refused the same
way, so its decode was retried on every render too.
The cache held each source Arc only to recognise it. Before #293 it keyed
entries by the raw address, which a freed source could hand to new bytes.
A Weak keeps that guarantee, since the allocation itself stays while the
Weak lives, but the bytes are freed with the document. The cache now
counts only what it decoded, and cacheable() no longer depends on the
source size.
Tests: the #3665 test caches its shrunk picture for a source larger than
the whole cache. media_cache_counts_what_it_keeps_and_lets_sources_go
replaces media_cache_counts_the_source_bytes_it_holds, which pinned the
old accounting, and the same-allocation test also checks that a freed
source's address isn't taken for a new one. Counting the source again
fails two tests; keeping a strong reference fails one.
* chore: resolve SonarCloud maintainability issues
* fix: restore compiling refactors, revert behaviour changes, run cargo fmt
- fontdb::norm: keep the closure for filter (char::is_alphanumeric takes
self, not &self, so it does not fit Iterator::filter).
- story.rs: write_mark_rpr needs &mut self (rev_attrs, rpr_change).
- Revert the viewport meta change and the return 0 added to
workspace_version/sha256, which changed behaviour or masked failures.
- cargo fmt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Import Document in odt page_parts after dropping glob re-export
* fix: apply_kind_properties binds ContentControl; cell_ref keeps char closures
* fix(engine): pass case helpers by value (clippy needless borrows)
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Dylan Taylor <dylan@craftmaker.dev>
* #1740: triple borders draw as three lines on screen and in PDF
Triple borders (tables, paragraphs, the ### AutoFormat line) were drawn as
double lines. Layout now emits a Triple stroke; the renderer and the PDF
exporter draw three thin lines across the line's direction, so vertical
table borders get three side-by-side lines too.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
* #1740: rebase onto main — triple border strokes use the line's f64 ends
Main now converts the line ends to f64 once and draws through a shared
offset-line closure; the triple stroke uses both instead of dereferencing
the shadowed values.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012WEhZXSxzS8orX7f9J3qpr
* #1740: review — PDF triple-border test checks the three strokes are distinct and 3 widths apart
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012WEhZXSxzS8orX7f9J3qpr
---------
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: aiongg <aiongtaigi@gmail.com>
- A page-number start near u32::MAX (.docx accepts up to 4294967295) or a line-number start
near u32::MAX (open through .json and commands) overflowed when the next page or line was
counted: a panic whenever overflow checks are on, silently wrapped numbers otherwise. The
three additions now saturate.
- The wave stroke used by wave borders and underlines looped forever, pushing curves until
memory ran out, once its x coordinate passed about 1e16 and `x + step == x` (a wave page
border with a 1e20 `space`, reachable through .json, the control channel and MCP). The
path is built in `wave_path`, which stops as soon as a step makes no progress.
Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Windows metafiles (WMF, EMF), common for logos, crests and diagrams in
older documents, couldn't be decoded and showed as grey boxes, on screen
and in PDF.
The new crate wordcraft-metafile (layer 1) reads them from the public
[MS-WMF] and [MS-EMF] specifications into paths and bitmaps, and places
them in a picture's box; render and pdf paint the result as vectors.
It covers the drawing records Office pictures use (lines, polygons,
curves, rectangles, ellipses, arcs, path brackets), pens and brushes,
the mapping modes and world transforms, and bitmaps in DIB form with the
usual raster operations. Input is treated as hostile: every read is
bounded, and a byte budget caps what one picture may allocate.
Not yet: text records (ExtTextOut) and EMF+ records are skipped, so a
metafile whose content is mostly text shows only its lines and fills.
docxide-pdf bench (365 documents, vs main + #135): the twelve documents
with WMF/EMF pictures show them; the pictures are a small part of their
pages, so the scores move little (Jaccard passes 208 -> 209, five
documents up to 3 SSIM points better, none worse).
Co-authored-by: Oliver Zieschang <4963183+naxvog@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Dylan M. Taylor
VoiceLessQ
divyanshu2074andBrandon Thomas
loganjandClaude Sonnet 5.5
