mirror of
https://github.com/tiennm99/ghstats.git
synced 2026-06-05 22:12:33 +00:00
tiennm99
e0e99b5774
When niceTicks picks a step that doesn't divide the data max, the last returned tick was the highest step multiple ≤ max. Callers used it as yMax, so any data point > lastTick rendered a bar > chartH that poked above the chart top into the title area. Concrete case from the dracula demo: max=625 with step=100 → ticks [0, 100, 200, 300, 400, 500, 600], yMax=600, bar height for 625 = 110*(625/600) = 114.58 — 4.58 px past the chart top and right against the card title. Fix in niceTicks itself: round the top tick UP to the next step multiple (`last = ceil(max/step) * step`), so 625 yields [..., 600, 700] and the same 625 bar lands at 110*(625/700) ≈ 98.2 px, with a clean 12 px gap to the title. This is the stable answer to title-vs-bar collision: regardless of which weekday (or year, or month, or hour) holds the peak, the chart headroom is built into the axis instead of leaned on per-card. The title auto-shrink from the previous fix still applies — that's for literal text width, an orthogonal problem. Add TestNiceTicksCoversMax covering the cases (625, 99, 101, 7, 49, 999, 1001) that would have silently regressed before.