7-segment-clock: digit_spacing >= 3 overflows the panel, but the schema allows up to 10

[ChuckBuilds]

Summary

7-segment-clock's config_schema.json allows digit_spacing from 0 to 10, but any value >= 3 pushes the clock off the right edge of at least one supported panel size. The renderer adds spacing between digits without re-fitting the glyph width, so the schema advertises settings that cannot render.

Only 0, 1, and 2 (the default) are safe on all eight sizes.

Reproduction

Plugin 7-segment-clock v1.0.5, LEDMatrix v3.3.0-4-g0730d952:

cd ~/LEDMatrix
python3 scripts/check_plugin.py -p 7-segment-clock -d ~/LEDMatrix/plugin-repos \
  --golden-dir /tmp/nogolden -c '{"digit_spacing": 10}'

Sweep across the full schema range (24h format, all other settings default)

digit_spacing	sizes overflowing
0	none
1	none
2 (default)	none
3	64x64, 128x96
4	64x64, 128x96
5	64x64, 128x64, 128x96
6	64x32, 64x64, 96x48, 128x64, 128x96
7	64x32, 64x64, 96x48, 128x64, 128x96
8	64x32, 64x64, 96x48, 128x64, 128x96, 256x128
9	64x32, 64x64, 96x48, 128x64, 128x96, 256x128
10	64x32, 64x64, 96x48, 128x64, 128x96, 256x128

Sample failures at digit_spacing: 10:

[FAIL]   64x32  7-segment-clock overflow bbox=(64, 2, 73, 30)
[FAIL]   64x64  7-segment-clock overflow bbox=(67, 16, 80, 48)
[FAIL]   96x48  7-segment-clock overflow bbox=(96, 2, 110, 45)
[FAIL]  128x64  7-segment-clock overflow bbox=(128, 3, 149, 60)
[FAIL]  128x96  7-segment-clock overflow bbox=(134, 15, 160, 80)
[FAIL] 256x128  7-segment-clock overflow bbox=(256, 16, 272, 112)

Turning on 12-hour format with has_leading_zero makes it worse — overflow starts at digit_spacing: 4 rather than 3, and 64x64/128x96 fail there too.

Interesting detail: 128x32 and 256x32 never overflow at any spacing, so the bug is specific to the taller layouts where the digits are already scaled up to fill the height.

Expected

Either the digits should shrink to absorb the requested spacing, or the spacing should be clamped to what fits, or the schema maximum should reflect what actually renders. Silently drawing past the panel edge is the one outcome that shouldn't happen.

Also worth a look while in here

--freeze-time was not used for this sweep, and the clock still renders deterministically enough to compare — but note that the committed goldens are for the default config only, so any config-varying run has to be given --golden-dir pointing somewhere empty or every size reports spurious "golden drift".

---

Found while installing and validating every catalogued plugin on a 256x64 rig.