A growable lr-tb row group that fits stays, one taller than a page goes on over pages, an rl-tb
one splits as lr-tb does, and one with a height or a positioned one moves whole. A table of
empty multi-line cells with a minimum height fits as many rows on a page as that height allows.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Pq7HyCfwzyRXj4VfQAVVdv
A flowing lr-tb or rl-tb subform without a height, laid out as one
block, moved whole to the next page when it didn't fit what was left of
this one. A subform is splittable "in margins and where consensus exists
among contained objects" (XFA 3.3 p. 1520), and readers start it on the
page and carry the rest over. It now does the same, as a block taller
than a page already did. One with a height still moves whole.
With the row-height fix before it, a public evaluation form's sections
shrank enough to fit a page, so they moved whole and left page 1 nearly
empty (3 pages, where readers lay the form out on 2). It is 2 again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBVyQEwtmEw3mS1MoAiwrK
An empty multi-line text field was laid out three lines tall (38.5pt in
the default 10pt font) before its minimum height applied, so a growable
table cell (minH, no h; XFA 3.3 p. 731) could never be as short as its
own minimum. Texas HHS Form 1060's activity table, ten rows of such cells
at minH 7.62mm, came out at 38.5pt a row instead of 21.6pt and ran onto
a third page; readers fit the form on two.
Such a field now starts at its minimum (one line, or its text, below it)
and still grows with its text. A multi-line field without a minimum keeps
its three lines.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CBVyQEwtmEw3mS1MoAiwrK
Export > Image spent its time in the PNG, JPEG and TIFF encoders, one
page after another: on a 55-page manual at 150 dpi, drawing every page
took about 0.34 s and encoding it 1.1 s (PNG) to 2.0 s (JPEG).
Exporter::images exports a list of pages, drawing and encoding several
at once on worker threads, each with its own PageRenderer (as
automation's extract_parallel does), and hands the files to a sink in
page order on the calling thread. Workers draw at most one page ahead
of the sink and fewer run when 1 GiB can't hold that many of the
largest page. The first page or sink error stops the export with every
earlier page handed over, as before. A page panic becomes that page's
error, and a panicking sink stops the workers. One page, one core or
wasm keeps the per-page loop. Export > Image and the doc_export_images
tool use it.
Files are byte-identical. One core is left for the interface (at most
8 workers). With examples/export_bench, on a Ryzen with 16 threads
(shared), mean of two medians of 21 runs:
PNG 150 dpi 1874 -> 340 ms (-82%)
JPEG 150 dpi 2106 -> 340 ms (-84%)
TIFF 150 dpi 2032 -> 375 ms (-82%)
PNG 300 dpi 3804 -> 590 ms (-84%)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
