no_std support? about swash HOT 8 OPEN

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.

from swash.

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

from swash.

I will be attempting to add this feature.

from swash.

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

from swash.

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

from swash.

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

from swash.

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.

from swash.

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.

from swash.