no_std support?

[xobs]

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.

[dfrg]

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.

[kirawi]

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]

I will be attempting to add this feature.

[lylythechosenone]

@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).

[notgull]

I was working on it but got distracted by other things. I can take another crack at it if it's important to you.

[lylythechosenone]

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).

[dfrg]

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.

[lylythechosenone]

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.

[lylythechosenone]

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.