Skip to content

fix(layout): keep the last row when the layout does not scale the content - #1590

Merged
marcinz606 merged 1 commit into
marcinz606:mainfrom
thetalkingdrum:fix/layout-keep-last-row
Nov 1, 2026
Merged

marcinz606 merged 1 commit into
marcinz606:mainfrom
thetalkingdrum:fix/layout-keep-last-row

Conversation

@thetalkingdrum

Copy link
Copy Markdown
Contributor

The preview and export layouts scaled a side through a float aspect ratio, int(w / (w / h)). For about one size pair in nine, that gives a value just under the true height, so an unscaled 1355 × 908 frame came out 907 rows high on the GPU and 908 on the CPU. The CPU and GPU renders then had different sizes.

The layout now scales with integer math in fit_content, paper_dims_from_long_edge, apply_layout and the GPU's _calculate_layout_dims. I did not bump THUMBNAIL_RENDER_VERSION, because a cached thumbnail can only be one row short.

…tent

The preview and export layouts scaled a side through a float aspect,
int(w / (w / h)). For about one size pair in nine that is h - 1e-13, so
an unscaled 1355 x 908 frame laid out at 1355 px came out 907 rows high
on the GPU, while the CPU render kept 908. NORAD 106-04 and 106-5 showed
it on main; CPU/GPU diffs had to crop to the smaller size.

fit_content, paper_dims_from_long_edge, apply_layout and the GPU's
_calculate_layout_dims now scale with integer math (w * h_img // w_img).
After the fix 106-04, 106-5, 106-16 and 106-03 render the same size on
both engines, mean diff about 1e-6.

THUMBNAIL_RENDER_VERSION is not bumped: a cached thumbnail can only be
one row short, and re-rendering every thumbnail for that is not worth it.
@marcinz606
marcinz606 merged commit fb7ac99 into marcinz606:main Nov 1, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants