Den lør. 8. jan. 2022 kl. 23.11 skrev Alexis King <lexi.lam...@gmail.com>:
> 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 racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CABefVgwmkK8FXeMNQ8WzoW50BDYzcZjtiBbiTGeby812UBCc%3Dw%40mail.gmail.com.
