Den lør. 8. jan. 2022 kl. 23.11 skrev Alexis King <[email protected]>:
> 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. > It seems to me that the ideal solution would be hybrid. 1. Expose public but explicitly *unsafe* direct access to Cairo and Pango contexts. 2. Implement a safe API in racket/draw that provides the necessary low-level access to fonts and glyphs. Where 2. is built on top of 1. Users are of course encouraged to use 2., but if some library needs low-level access it's available. Wrt to Cairo I have bindings for most C-level functions here: https://github.com/soegaard/cairo/blob/main/cairo-lib/cairo/bindings.rkt On top of these I have implemented a shallow object oriented layer following the recommendation on the Cairo web-site. It's shallow in the sense that it is still lower-level than racket/draw. https://github.com/soegaard/cairo/blob/main/cairo-lib/cairo/main.rkt Note: These bindings haven't been tested as thoroughly as I usually test my code. I still haven't had time to use them in a larger project. /Jens Axel -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CABefVgwmkK8FXeMNQ8WzoW50BDYzcZjtiBbiTGeby812UBCc%3Dw%40mail.gmail.com.
