fix(print-layout): match proportional legend sizes to map

[giswqs]

Summary

• carry the captured map's device-pixel ratio into print layout rendering
• scale proportional legend symbols by the same image-fit transform as the map
• grow legend rows and swatch columns to the symbols' true rendered footprint

Verification

• reproduced with the reporter's ruchers_018.csv dataset and nb_ruches proportional sizing
• verified the Print Layout preview at the original scale and at 1:100,000
• verified in light and dark themes
• added a regression test covering device-pixel ratio and map-image fit scaling
• node --import tsx --test tests/print-layout.test.ts --test-name-pattern='drawLayout legend rendering'
• npm run build
• pre-commit run --files ...

Refs #1711 (comment)

Summary by CodeRabbit

• Bug Fixes

  • Improved print layout previews and atlas exports to scale map legends and proportional symbols accurately across different display resolutions.
  • Ensured custom SVG markers maintain the correct size when maps are fitted to pages.
  • Prevented oversized proportional symbols from being omitted from legend rows.
  • Limited legend-item resizing to only entries that require it, preserving consistent sizing elsewhere.

• Tests

  • Added coverage for proportional marker scaling across map resolutions and display pixel ratios.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 26a5e9b4-0c23-48b2-a721-a43a9b596889

📥 Commits

Reviewing files that changed from the base of the PR and between d726fb2 and 55aa5f9.

📒 Files selected for processing (2)

• apps/geolibre-desktop/src/lib/print-layout.ts
• tests/print-layout.test.ts

---

📝 Walkthrough

Walkthrough

The change propagates captured map pixel ratios through print layout and atlas export flows. Legend symbols now use fitted map scale and pixel ratio. Proportional legend rows derive dimensions from rendered radii and receive entry-specific overflow scaling. Tests cover fitted scaling and oversized symbols.

Changes

Pixel-ratio-aware print layout

Layer / File(s)	Summary
Capture metadata and layout wiring apps/geolibre-desktop/src/lib/print-layout-export.ts, apps/geolibre-desktop/src/components/layout/PrintLayoutDialog.tsx	CapturedMap reports pixelRatio. Preview layouts, atlas scale calculations, and atlas exports receive this value.
Legend symbol scaling and overflow handling apps/geolibre-desktop/src/lib/print-layout.ts, tests/print-layout.test.ts	Legend symbols use fitted map scale and pixel ratio. Proportional rows derive dimensions from rendered radii, cap oversized rows, and scale only affected entries. Tests verify these behaviors.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant captureMapImage
  participant PrintLayoutDialog
  participant print_layout
  captureMapImage->>PrintLayoutDialog: return CapturedMap.pixelRatio
  PrintLayoutDialog->>print_layout: pass mapPixelRatio to layout and atlas options
  print_layout->>PrintLayoutDialog: render scaled legend symbols and atlas layouts

Loading

Possibly related PRs

• opengeos/GeoLibre#1548: Both modify proportional-symbol legend sizing in print-layout.ts.
• opengeos/GeoLibre#1699: Both modify legend row sizing and overflow handling in print-layout.ts.
• opengeos/GeoLibre#1722: Both modify proportional legend sizing and rendering in print-layout.ts.

Poem

A rabbit tracks each pixel’s glow,
As fitted legend symbols show.
Tall rows shrink and stay in view,
Atlas pages render true.
Hop, hop—the scales align!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: matching proportional legend sizes to the captured map.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/discussion-1711-layout-legend-scale

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint install failed: dependency version conflict. Check your lock file or package.json.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔍 Cloudflare PR preview

Item	Value
Site	https://54373b4d.geolibre-preview.pages.dev
Demo app	https://54373b4d.geolibre-preview.pages.dev/demo/
Commit	55aa5f9

[github-actions]

🔍 GitHub Pages PR preview

Item	Value
Site	https://opengeos.org/pages-preview/GeoLibre/pr-1779/
Demo app	https://opengeos.org/pages-preview/GeoLibre/pr-1779/demo/
Commit	55aa5f9

Note

GitHub Pages built this preview successfully, but its serving edge returned HTTP 403 when checked. The links may still be propagating.

[github-actions]

Code review

Bugs

• apps/geolibre-desktop/src/lib/print-layout.ts:2039 — Removing the old MAX_CIRCLE_R cap makes swatch/rowH grow unboundedly with maxSizedRadius, which is independent of the page's unit/resolution. This breaks the assumption behind the nearby if (fitRows === 0) return 0; early-return (its comment claims maxHeight "always clears ~24 rows whatever the paper size" — no longer true once row height is uncapped). A single outsized proportional symbol on the live map (plausible for the exact use case this PR targets) can make one row's height exceed maxHeight, causing the entire legend — including unrelated, normally-sized entries — to silently disappear instead of just eliding extra rows. Confidence: medium (traced the math, not reproduced live).

Security

• None found.

Performance

• None found; the added scaling math is O(1) per legend entry/swatch and doesn't change the function's complexity.

Quality

• The core fix (threading pixelRatio through CapturedMap → LayoutOptions → mapSymbolScale = dpr * coverScale) is applied consistently at all three LayoutOptions construction sites in PrintLayoutDialog.tsx, and the removal of the old per-row rowScale/entryScale clamp logic is clean with no dangling references. The new regression test (tests/print-layout.test.ts) correctly verifies the dpr × coverScale math against two different capture widths. High confidence this part is correct and well-tested.

CLAUDE.md

• No violations noted; changes stay within apps/geolibre-desktop and don't touch any of the mirrored-constant modules called out in CLAUDE.md.

[github-actions]

Posted successfully. That's the only substantive finding worth flagging — everything else in the diff checks out cleanly against manual arithmetic and the new tests.

Code review

Bugs

• symbolScale in drawLegend (print-layout.ts:2033-2059) is now computed as a single global scalar from the largest sized symbol across all legend entries, rather than per-entry as the deleted code (and the still-live on-map MapLegendPanel.tsx) did. When one proportional-symbol layer has an outlier value large enough to trip swatchCap, every other proportional-symbol layer in the same legend gets uniformly shrunk too, even if it would have fit and rendered 1:1 with the map on its own — undercutting this PR's stated goal for the non-outlier layer. Confidence: medium (only manifests with multiple differently-scaled proportional layers in one legend; not exercised by the new tests).

Security

• None found. No user input, network, or injection surface in the changed files.

Performance

• None found. The changes are O(entries)/O(rows) canvas math, same order as before.

Quality

• The pre-existing comment near print-layout.ts:2065-2066 ("entryId keeps proportional scaling scoped to one legend entry...") is now stale/misleading — entryId is stored on each row but never read again after this refactor removed the per-entry entryScale logic it used to describe. Same root cause as the Bugs item above; worth updating together. Confidence: high (verified via grep — no other reads of entryId).

CLAUDE.md

• No violations found. Change is confined to print-layout internals; no i18n strings, tile hosts, WASM catalogs, or other tracked mirrors are touched.

Everything else — the pixelRatio/mapPixelRatio threading through PrintLayoutDialog.tsx (all three LayoutOptions construction sites updated consistently), the coverScale/mapPixelRatio combination math in mapSymbolScale, the new swatchCap/wantedSwatch derivation, and the two new regression tests — checked out correctly against manual recomputation of the geometry (computeBodyRect, coverScaleFor).

[github-actions]

Code review

I traced the full scaling chain (captureMapImage's new pixelRatio → PrintLayoutDialog's three LayoutOptions construction sites → drawLayout's mapSymbolScale → drawLegend's swatch/row sizing) and independently recomputed the arithmetic in all three new regression tests (fit-scale scaling, outsized-symbol capping, per-entry scoped shrink) against the implementation — the numbers match exactly, including the boundary case where the capped entry's radius lands precisely at swatch / 2.

Bugs

• None found. Edge cases checked and confirmed safe: mapSymbolScale degrading to 0/1 when no map image is captured, division-by-zero avoided in entryScale (guarded by the entryMax > swatch/2 conditional), swatchCap staying ≥ unit*2 even when maxHeight - chromeH goes negative, and the chromeH hoist removing the old duplicate declaration cleanly.

Security

• None applicable — this is pure canvas layout arithmetic with no external input, injection surface, or secrets involved.

Performance

• Negligible: the new Math.max(max, ...entry.swatches.map(...)) spread inside reduce is O(entries × swatches) computed twice, which is fine for realistic legend sizes. Low confidence this is worth changing given rows are truncated to fit maxHeight anyway.

Quality

• Low confidence, non-blocking observation: because the swatch column width is still shared across the whole legend box (pre-existing design, not introduced here), a legend combining several small categorical entries with one layer that has a very large live-map proportional symbol will now inflate all rows' height up to the swatchCap-bounded value, more aggressively than the old fixed 1.5× multiplier could. This matches the PR's stated intent ("1:1 with the map") and is well-commented, so likely fine as designed — flagging only for awareness.
• All three LayoutOptions construction call sites in PrintLayoutDialog.tsx (live preview, atlas scale-mode capture, atlas export loop) were updated consistently with mapPixelRatio; no site was missed.
• CapturedMap.pixelRatio is a new required field, but captureMapImage is its only construction site in the repo, so no other callers needed updating.

CLAUDE.md

• No violations. This PR doesn't touch any of the version-mirrored constants (geolibre-wasm, maplibre-gl-vector, maplibre-gl-components, maplibre-gl-style-spec) or add user-facing strings requiring i18n, and the new test lives under tests/*.test.ts per convention.

No inline comments posted — nothing rose to a level worth flagging on specific lines.