Charts: add a Pareto chart (sorted bars with cumulative percentage line) #1819

Activity

1. ticket-craft commented on Oct 18, 2026

   

   ticket-craftBot

   on Oct 18, 2026 – with Ticket-Craft

   More actions

   Possibly related: #1267 and #1820.
2. ticket-craft

   added

   priority: low

   on Oct 18, 2026
3. iluebbe commented on Oct 23, 2026

   

   iluebbe

   on Oct 23, 2026

   More actions

   #1826 checked

   Fixes most of it. insert.chart {"type":"pareto"} makes a real Pareto chart with sorted columns and a cumulative line, it survives save and reopen, and Excel opens it as a Pareto. One rendering problem: the cumulative line is drawn against a 0–100% scale while the right-hand axis is labelled 0–120%, so the line and the labels disagree.

   Setup: PR head bae3772, merged locally into main at a1c8454, Windows 11. Checked with:

   • the PR's tests and a temporary render probe;
   • gridcraft-cli from the PR and from main;
   • Excel for Microsoft 365 through COM, to open the PR's file.

   Case	main	PR
   insert.chart {"type":"pareto"} over Cause/Count (B 20, A 50, C 10, D 5, E 15)	silently becomes a clustered column chart	Pareto, columns in the order A, B, E, C, D
   Save and reopen	—	still Pareto; written as a chartex part with clusteredColumn + paretoLine and a 0–1 percentage axis
   The saved file in Excel	—	opens without a repair prompt; chart type 122 (Pareto), no legend, secondary axis fixed at 0 to 1

   Problems:

   • The right-hand axis comes from nice_scale(0.0, 1.0, true), which adds headroom, so its labels run 0%–120%. The cumulative line, however, maps 0–100% onto the full plot height. In the example above:

     • the line ends at the "120%" label, not at "100%";
     • A's cumulative 50% sits on the "60%" gridline.

     Excel opens the same saved file with that axis at 0–100%.

     gridcraft/crates/chart/src/render.rs

     Line 1347 in bae3772

     let ys2 = nice_scale(0.0, 1.0, true);

     and

     gridcraft/crates/chart/src/render.rs

     Lines 1383 to 1384 in bae3772

     	let frac = (cum / total).clamp(0.0, 1.0) as f32;
     	pts.push([x, plot.bottom() - frac * plot.h]);

     . A fixed 0–1 scale with a 0.2 step would match.

   Merging: conflicts with main at a1c8454 in crates/ui-egui/src/i18n.rs (main moved the Japanese table to i18n/ja.rs) and in docs/chart-parity.md and docs/target-app-parity.md. Beyond the conflicts, merging needs:

   • CatAxis::Labels(&labels, &[]) in pareto(), because main's multi-level category axis gave CatAxis::Labels a second argument;
   • category_levels in four new ChartData literals in the chart tests;
   • the two Japanese strings moved into i18n/ja.rs. Otherwise i18n::ja::tests::covers_every_key_the_portuguese_catalog_translates fails.

   It also overlaps with:

   • Charts: draw every doughnut series as a ring #1827: both append to the same test files and docs; trivial.
   • Charts: work and memory are bounded by series x points; ranges are clipped before evaluation (#1147) #1155 and Charts: series on the secondary axis, fixed axis bounds and units, secondary axis title (#1267) #1290: the same use and pub use lines in render.rs and chart/src/lib.rs (trivial).
   • Charts: resolved data and rendering are cached between frames (#1139) #1140: both change the chart render call in chartview.rs. With Charts: resolved data and rendering are cached between frames (#1139) #1140's cache, the translated "Cumulative %" label would also need the UI language in the cache key.

   Tests (merged with main, with the fixes above): cargo test -p gridcraft-chart 44 passed, -p gridcraft-model 23, -p gridcraft-xlsx 250, -p gridcraft-engine --lib 391. -p gridcraft-ui-egui --lib: 150 passed and 1 failed (the Japanese catalog test above, a merge leftover). cargo clippy -p gridcraft-chart -p gridcraft-xlsx -p gridcraft-engine -p gridcraft-model -p gridcraft-ui-egui --all-targets -- -D warnings and cargo fmt --all -- --check are clean.