Issue #618: align Y axis tick labels on advance width

[timmolter]

Fixes #618.

The bug

setYAxisLabelAlignment(TextAlignment.Right) did not right-align every Y-axis tick label — labels beginning with 1 sat visibly right of their neighbours.

AxisTickLabels measured each label by the ink width of its glyph outline (outline.getBounds2D().getWidth()) but then drew it by translating to the computed x position and filling that same outline. The outline's ink does not begin at its origin — it begins at the left side bearing, getBounds2D().getX(), which the measurement discarded but the fill still honoured. The rendered right edge therefore landed at xOffset + maxTickLabelWidth + leftSideBearing instead of at a constant x.

Digit 1 has by far the largest bearing of any digit, which is why it was the visible outlier. Measured at SansSerif 30pt over labels 0–14:

label	bearing	ink width	rendered right edge
0	1.904	15.176	33.473
1	4.512	11.572	36.080
4	1.538	15.366	33.106
10–14	4.512	~30	36.080

The right edge tracks the bearing one-for-one. The spread is 2.97px, and it scales linearly at 9.9% of the font size — the ~1px wobble in the original report at default size, much worse on large fonts and HiDPI.

Left and Centre were affected by the same root cause.

The fix

Measure and align on advance width instead. The advance is the distance the pen moves, so it accounts for both side bearings and places each glyph exactly where the font intends. Digit advances are tabular, so equal-length labels now share a drawing origin and the labels form a true column:

label   advance   oldRightEdge   newOrigin
0        19.000         33.473      19.000
1        19.000         36.080      19.000
4        19.000         33.106      19.000
10       38.000         36.080       0.000
14       38.000         36.080       0.000

The width and alignment maths now live in a shared TickLabelMetrics, because the two call sites had drifted apart: ColocatedSlaveLabels aligned using the integer shape.getBounds() while measuring its column with TextLayout.getBounds(), adding up to a further 1px of quantisation.

Note on what "right-aligned" means here

This aligns advance boxes, not ink edges — so 1, being a narrower glyph, sits slightly inset within its tabular advance box rather than flush. That is deliberate and is what a spreadsheet column does: it keeps the tens digits of 10–14 in a single column, which pure ink alignment would break. Residual ink raggedness drops from 2.97px to 1.76px at 30pt; what remains is right-side bearing, a property of the glyph outlines that tabular alignment neither can nor should remove.

Verification

• RegressionIssue618Test — 7 headless tests asserting the geometry directly (no XChartPanel, so it runs on CI): equal-length labels share an origin, the advance column is exact, Left/Centre invariants hold, rendered ink stays inside the column, and the ragged edge is strictly smaller than the pre-fix maths.
• TestForIssue618 — a standalone demo following the existing standalone/issues convention; prints both old and new alignment maths, then displays the chart.
• Full xchart suite: 161 tests, all passing.

Before / after, bottom of the Y axis at 30pt — 1 no longer sticks out:

before: 1 sits ~3px right of 0, 2, 3, 4
after: digits form a clean column

🤖 Generated with Claude Code