On Sun, Jan 9, 2022 at 3:48 PM Jens Axel Søgaard <jensa...@soegaard.net> wrote:
> 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. > I agree that, for *users*, this would indeed perhaps be ideal. But from the perspective of the maintainers of racket/draw, I think it’s really the worst of all possible worlds: - It requires doing all the same work to design and build the safe API in the first place, and it commits to upholding the associated maintenance burden. - It leaves open the possibility that users will use the unsafe API, which means racket/draw cannot rely on all interactions going through a blessed code path. Moreover, it must document enough of the internals of its safe API to allow unsafe code to cooperate with it, so changing racket/draw’s implementation would likely be backwards-incompatible (and switching to a different set of libraries altogether definitely would be). On the whole, I think there probably isn’t much benefit to exposing the unsafe API if the safe API exists, and the maintenance burden is enough to discourage doing so. ------------------------------ On Wed, Jan 12, 2022 at 6:05 PM Philip McGrath <philip.mcgr...@gmail.com> wrote: > I think one of the more common requests has been more control over font > loading and resolution, e.g. to load a font from a file rather than relying > exclusively on the system's installed fonts > I agree with this, but I think this is mostly an orthogonal concern. If implemented, this would make sense to expose through the existing (safe) API. The Unsafe Libraries <https://docs.racket-lang.org/draw/unsafe.html> > chapter of the racket/draw docs leaves open the possibility that the > representation of handles may "change if the racket/draw library is > implemented differently in the future." > Yes, this is a great point that I had overlooked, as it means there’s already precedent for exposing some unsafe guts with reduced compatibility guarantees. With that in mind, I think I’ll try going down the unsafe API route and feeling out how large the exposed surface area would actually have to be. If it’s small enough, I suspect racket/draw/unsafe/cairo-lib is enough precedent to justify the additions. 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/CAA8dsac6XQJk3O_b64AX-OtNev96%3DwqrSCyKbWpg-vWpiq8qrQ%40mail.gmail.com.
