Share Linux FreeType Text Support Across MewUI Backends

[maikebing]

Hi, I’d like to discuss how Linux/FreeType text support should be shared across MewUI backends.

Currently, MewUI.Backend.MewVG.X11 consumes the existing Shared/Rendering/FreeType sources by linking them into the backend project with . We are adding/maintaining a Linux framebuffer backend, and it needs the same FreeType text stack: font resolution, FreeType font objects, measurement, rasterization, fallback fonts, and the native FreeType/HarfBuzz/Fontconfig bindings.

For our local repository, we can follow the existing pattern and source-link the same shared FreeType code into the framebuffer backend. That keeps the change small and avoids changing MewUI core too much.

Longer term, though, source-linking the same FreeType implementation into multiple backend assemblies feels like it may become harder to maintain. It also creates pressure to expose internal MewUI types or use InternalsVisibleTo, neither of which seems ideal for third-party or external rendering backends.

Would you be open to introducing a small shared FreeType support project/assembly in MewUI, for example:

Aprillz.MewUI.Rendering.FreeType

Its purpose would be to host the existing Linux FreeType text implementation and native bindings in one place, so Linux backends can reference it instead of recompiling the same shared sources.

Potential scope:

FreeType font creation and font path resolution
Text measurement
Text rasterization to BGRA bitmap data
Font fallback handling
FreeType/HarfBuzz/Fontconfig native bindings
A small public surface designed for backend authors, while keeping implementation details internal
This would let backends such as MewVG.X11 and a framebuffer backend share the same FreeType implementation without duplicating compilation, and without requiring broad changes to MewUI core font APIs.

Some questions I’d like your opinion on:

Do you prefer the current source-linking model for backend-specific shared code?
Would a separate FreeType support assembly fit MewUI’s package structure?
If yes, should the API expose low-level types like FreeTypeFont / rasterized TextBitmap, or should it expose a smaller service-style API for measure/rasterize?
Should this be a separate package, or only an internal project referenced by Linux backends?
For now, we can keep our framebuffer backend using source links to match the existing MewUI pattern. I’d like to understand what direction you’d prefer before making a larger upstream-facing change.