swash
swash copied to clipboard
dfrg
no_std support?
Will this library ever add no_std support?
I ask because it's not in the Non Goals section of the README, yet it does not appear to have any allocations or use any features from libstd.
Shaping and scaling unfortunately do require heap allocations due to indeterminate memory requirements or upper bounds that are too large for stack allocation.
That said, the crate could be core+alloc, but certain components of the underlying path engine require floating point intrinsics that are currently unavailable in core. This is a known problem and when it is resolved, I would like to remove the std dependency.
It doesn't seem like there's been any work towards it in the aforementioned issue for ~3 years. It might be worth feature gating it with support for libm or micromath? Not really familiar with this kind of stuff, though. std::io and yazi might still be an issue, but probably solvable with traits.
Edit: Proof of Concept (I won't actually be implementing this, I'm too busy.)
@jackpot51 Are you on this?
It does seem like it'll be a while before math-in-core is stable. I think it would certainly be worth using something like libm in the mean time.
As for std::io, what's the status on that? I know we won't be getting core::io for a long time (mainly due to std::io::Error), so some alternative approach would likely be useful. Assuming it's only used in the loader, I think delegating to an external loader, like rustybuzz and many other crates do, could actually be worthwhile. For example, ttf-parser, which is used in rustybuzz, already supports no_std.
yazi does now support no_std (as seen in this thread).
I was working on it but got distracted by other things. I can take another crack at it if it's important to you.
I was actually thinking about using swash for early console rendering inside of my OS, so I'd love it if you could add support. I can also try to help out with anything, as I have lots of experience with no_std (see said OS).
Thanks to @notgull, all dependencies should support no_std now. Doing so for swash is mostly grunt work that involves integrating libm and importing alloc::vec::Vec where required. I don’t really have time to do it myself but I’m happy to accept a PR.
Something I've seen in a lot of other crates is simply extern crate alloc as std;. This allows you to keep the old code that uses std, and simply switch it out for alloc in no_std.
Wow, I totally forgot about this. I'd love to try to get something like that done this week, if the story is still the same.