[222_46] display consistent normalized font size across status bar and font size selector

[1sh-repalto]

Fixes #2808
Decimal font sizes not displayed correctly in status bar and font size selector

---

Summary

Normalize font size display to the nearest 0.5 across the status bar and font size selector, ensuring consistent and accurate representation.

Developer document: devel/222_44.md

---

Issues Found

• In edit_footer.cpp, get_env_int(FONT_BASE_SIZE) truncates decimal values to integers.
• The display lines also use (int) casts, discarding any fractional part.
• The font size selector in document-menu.scm displays raw user input without normalization.
• The font rendering engine only supports size changes at 0.5 increments (via normalize_half_multiple_size), arbitrary decimals like 10.3 are internally rounded to 10.5 but displayed as 10.3, causing a mismatch.

---

Changes

• Changed get_env_int to get_env_double for FONT_BASE_SIZE in edit_footer.cpp to preserve decimal values.
• Replaced (int) cast with round(x * 2.0) / 2.0 normalization for text, math, and prog modes in the status bar.
• Updated font-base-size-menu-name in document-menu.scm to display the normalized font size instead of raw user input.
• Added init-font-base-size-interactive to sanitize the "Other" input dialog — invalid or non-numeric entries default to 10.
• Reused font-base-size-menu-name in fold-menu.scm for the beamer toolbar instead of raw string display.

---

How to Test

Go to Font Size -> Other, then:

1. Set font size to 10.5 — status bar and selector should both show 10.5
2. Set font size to 14.2 — both should show 14 (rounded to nearest 0.5 with no trailing .0)
3. Set font size to 14.25 — both should show 14.5 (rounded to nearest 0.5)
4. Enter "abc" — should default to 10 without errors

how_to_test.mp4

[1sh-repalto]

Hi, another approach I thought to handle invalid input from the user is to show an error dialogue message. Let me know if this needs to be implemented, I'll create a seperate issue for it. Thanks!

[MoonL79]

Thanks for the fix.

The core logic looks good overall (consistent 0.5-step normalization and using get_env_double in the footer). The only significant issue I found is in the new Other input path:

• init-font-base-size-interactive currently accepts any numeric value, including 0 and negative numbers.
• This should be validated as a positive font size (> 0) before writing font-base-size; otherwise fallback to 10 (as you already do for non-numeric input).

Suggested change:

• In init-font-base-size-interactive, treat values as valid only when numeric and > 0.
• Optional hardening: apply the same positivity guard in font-base-size-menu-name so legacy/invalid stored values are also handled safely.

So yes, I think the main follow-up needed for this PR is adding the positivity check in the Other handler.

[1sh-repalto]

Thanks for the review! I've added the positivity check — both init-font-base-size-interactive and font-base-size-menu-name now validate (and num (> num 0)), so zero and negative values fall back to the default of 10, same as non-numeric input.
Let me know if more changes are needed.

handle-zero-and-negative-input.mp4

[MoonL79]

LGTM