Desktop native bindings

[be5invis]

I am wondering if you are interested in working on desktop native bindings:

• Windows: Renders RaTeX content to ID2D1DeviceContext.
  • You may probably need two variants:
    • Rust crate for Rust and C++ programs
    • C# bindings for C# programs
• Macintosh: Renders to CG/CT, probably we can reuse existing iOS bindings
• Linux: Probably a Skia bindings or Cairo bindings

[techwizrd]

I'm not @erweixin but I wouldn't mind some native C/GObject Cairo bindings for Gtk/GNOME. I'll give it a shot.

[techwizrd]

I tried this two ways for Linux: converting the glyph outlines into Cairo paths (shown below), and doing native glyph rendering through FreeType/Cairo. I've create C/GObject bindings for Gtk/Gnome as well, so it can be used via Rust, C, Python, Vala, etc.

The outline approach is the boring-but-reliable one. We treat each math glyph as vector geometry, turn the font outline into Cairo path commands, and paint it the same way we already paint rules, paths, and boxes. That fits RaTeX pretty well today because it stays close to the existing display-list model, works the same in GTK and the shared Cairo backend, and gives us direct control over ordering, transforms, and fallback behavior. The tradeoff is that these are no longer "real" text runs from the platform’s point of view. We are painting shapes, so we do not get backend-specific hinting, font-stack optimizations, or native text API behavior for free.

The native glyph/FreeType approach instead tries to hand Cairo actual font faces plus glyph IDs and let the platform font stack render those glyphs natively. This is probably better long-term for GTK if we want KaTeX font usage with native rasterization quality, and it is also the better foundation for a future GObject-facing widget that behaves like a first-class text-rendering control. But it is also much more fragile: the font face, glyph ID mapping, scaling, baseline positioning, and fallback behavior all have to line up exactly with RaTeX’s layout assumptions. A small mismatch in any of those layers can produce severely broken output, whereas the outline renderer is comparatively boring and reliable because it bypasses most of that complexity. Honestly, I couldn't get this to work robustly, so I'd suggest the Cairo outline approach for now.

[jangernert]

@techwizrd just out of curiosity: why not go with Gtk.Svg? That's how I approached embedding RaTeX into my Gtk application. Gtk can then render the Svg as part of its scene graph on the GPU and with some slight modifications to the Svg output you get things like color changes in dark mode for free.

[techwizrd]

Gtk.Svg is a good idea, and probably worth supporting as an optional GTK backend. I didn’t start there mainly because it is GTK-only and very new: Gtk.Svg landed in GTK 4.22, while a Cairo renderer works across older GTK4 installs and also maps to non-GTK Linux/C/GObject use cases.

There are also some RaTeX-specific tradeoffs. The default SVG output uses <text> plus KaTeX fonts, so the host has to provide the right fonts/CSS. The standalone SVG path embeds glyph outlines, but at that point it is conceptually very close to the Cairo-outline backend, just with an extra SVG serialization/parsing layer. The Cairo path also gives the widget direct control over sizing, baseline metrics, fallback behavior, colors, and error handling.

I could probably implement a Gtk.Svg backend tonight and leave the Cairo as a fallback.

[jangernert]

If you want to take a look at my very basic implementation, its here:

https://gitlab.com/news-flash/html2gtk/-/blob/master/src/math_renderer/ratex.rs?ref_type=heads

[techwizrd]

I have an initial implementation but I need to benchmark it. Gtk.Svg may be slower because RaTeX must serialize SVG, GTK must parse SVG, and standalone glyph paths can be large. The current Cairo path is direct since the DisplayList just gets drawn by Cairo. That extra middle layer is only worth it if GTK’s retained paintable/render-node caching amortizes the cost over many redraws, or if GTK-native theming/scene-graph integration is more important than first-render speed.

[techwizrd]

@jangernert Initial render/construction path is slower with Gtk.Svg here at roughly 1.8x Cairo on average. I benchmarked SVG generation + symbolic rewrite + Gtk.Svg::from_bytes, rather than retained redraw performance.