Render and input text in languages other than English on macOS

[hard25670559]

Problem

The bundled bitmap fonts carry only the first 128 codepoints, so every other character is drawn as a [U+XXXX] placeholder. Typing through an input method does nothing visible at all: the composition never reaches the application, keys the IME is about to consume also hit the UI, the candidate window opens in a screen corner, and committed text is turned into ? on the way in.

Together this means build names, notes, account names and item text pasted from a localised client are effectively limited to ASCII, whatever language the user works in. PathOfBuildingCommunity/PathOfBuilding#5632 has been open on this since early 2023; users there resort to third-party rebuilt engine binaries.

Changes

Glyph rendering — a parallel path rather than a replacement. A new macOS module rasterises a codepoint on demand through CoreText; going via CTFontCreateForString uses the system fallback chain, so Han, kana, Cyrillic and emoji all resolve with no font to bundle or curate. r_font caches these per (codepoint, size) as small textures and consults them in the three places that previously produced tofu — width measurement, cursor hit testing and drawing. Latin text still goes through the bitmap fonts untouched, so existing layout is unchanged, and tofu remains the fallback when no glyph exists anywhere.

Glyphs are rasterised at the display's pixel density and scaled back to layout units so they stay sharp on HiDPI, and are anchored to a fixed fraction of the line height: a font's own ascent includes leading and sits noticeably below where the bitmap fonts place their baseline.

Input method support — GLFW's content view conforms to NSTextInputClient but leaves several parts inert, so those are replaced at runtime and chained to the originals rather than forking the library:

• setMarkedText: forwards the composition to the UI so it can be drawn at the caret; unmarkText clears it.
• firstRectForCharacterRange: answers with the caret rectangle the UI reports, so the candidate window follows the text.
• markedRange was one unit short of the text it holds and selectedRange was missing entirely — both are consulted while positioning the candidate window, and a bad answer makes the system give up on it.
• keyDown: withholds keys from the application while composing. GLFW reports the raw key first, which let Return confirm a dialog before the composed text arrived.
• insertText: clears the marked text GLFW leaves behind on commit, which otherwise kept every later keystroke away from the application.

UI plumbing — character events carry the codepoint encoded as UTF-8 instead of being looked up in the key name table, which only knows named keys and answered ? for anything above ASCII. Composition state is delivered through a new OnPreedit callback, and SetIMECaretRect lets the focused control report where its caret is.

Dependencies

• Includes the one-line fix in Fix null dereference when building a texture from memory PathOfBuildingCommunity/PathOfBuilding-SimpleGraphic#112 — the texture constructor used for glyph atlases dereferences null without it. Happy to rebase once that lands.
• The application half (drawing the composition, reporting the caret) is Handle multi-byte characters correctly in text fields PathOfBuildingCommunity/PathOfBuilding#10194 plus a follow-up; the Lua side degrades gracefully if SetIMECaretRect is absent.
• The display-density fix is submitted separately as Correct the drawing surface density on non-HiDPI displays #1 and is not included here.

Verification

Built for arm64-osx and run on a three-display setup.

• CJK, Latin and mixed text render correctly and stay sharp on a 2x display; Latin-only layout is byte-identical in appearance.
• Composition appears underlined at the caret, the candidate window follows it, Return commits without confirming the surrounding dialog, and backspace/arrows behave normally afterwards.
• Verified with the system Bopomofo input method and with a third-party one.

Known limitation

With the system Bopomofo input method the candidate window appears at a stale position for the first character of a session and corrects itself once you move through the candidates. It picks that first position from a cached caret location without querying the application; other applications on the same machine behave identically. Third-party input methods are unaffected.

[hard25670559]

Also submitted upstream as PathOfBuildingCommunity#114. Same reasoning as #1: the change belongs to the engine, but it was developed and verified on this branch because master does not currently produce a working macOS build there. Happy to close this one if you'd rather it land upstream first.