On Sun, Jan 9, 2022 at 3:48 PM Jens Axel Søgaard <[email protected]> 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 <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAA8dsac6XQJk3O_b64AX-OtNev96%3DwqrSCyKbWpg-vWpiq8qrQ%40mail.gmail.com.
