Hi all, I have recently been tinkering with an implementation of an OpenType math renderer in Racket. Doing this properly requires consulting font metrics stored in the OpenType MATH table <https://docs.microsoft.com/en-us/typography/opentype/spec/math>. There is no direct interface to access these metrics in Pango, but they can be accessed by dropping down to the relevant HarfBuzz APIs <https://harfbuzz.github.io/harfbuzz-hb-ot-math.html>.
In my experiments so far, I have been getting access to these metrics by importing racket/draw/unsafe/pango and racket/draw/private/local and using private APIs to make the necessary FFI calls myself. However, this is obviously not a great long-term solution, especially since some of the information I’d like to get my hands on isn’t even directly accessible through the private APIs. Therefore, I would like to add public APIs for somehow accessing this information using racket/draw. This raises some API design questions, as there is not much precedent in racket/draw for exposing these nitty-gritty details of fonts. The font% class is really closer to a font description than a concrete font face, which is why even the most rudimentary methods for getting information about fonts, such as glyph-exists?, are actually methods of dc<%>, not font% itself. What’s more, such methods do not query font information directly: even glyph-exists? may perform font substitution. Much of this complexity is inherent to the problem of text layout and rendering, and racket/draw generally tries to hide it as much as possible. Unfortunately, those abstractions are at least somewhat at odds with my goal of implementing a math renderer, since I need to get fairly low-level access to font information. This leaves me considering two possible ways forward: 1. Expose public but explicitly *unsafe* direct access to Cairo and Pango contexts, and allow third-party libraries to make the necessary FFI calls themselves. 2. Implement a safe API in racket/draw that provides the necessary low-level access to fonts and glyphs. The second option sounds compelling, since safety is obviously preferable to unsafety, but the required API surface area would be pretty large: it would essentially amount to exposing a significant portion of HarfBuzz. That would create a significant backwards compatibility burden for racket/draw, and probably for relatively little gain, since most users have no need to get at any of this information. I’m therefore leaning towards the former, but I’d like to know if this sounds like a reasonable conclusion to others before doing this work. Thanks, Alexis -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAA8dsafSXkZdnDZdLreOWtMS2opiVs%3Dj8cMgTyBtnnUxMYhHkA%40mail.gmail.com.
