greyblake
Make crate no_std compatible
This patch makes the crate compatible on no_std (embedded) environments. The API stays the same. If possible, please publish a new version after merging.
@fschutt Hi, thanks for the PR! Just out of curiosity: is there any real use case whatlang and no_std?
Yes, because together with https://github.com/yeslogic/allsorts/pull/42 and https://github.com/hsivonen/encoding_rs/pull/66 I can then port azul-text-layout to no_std, so that I can get a text-layouting crate to work on embedded hardware. Eventually, this will enable embedded support for the entire https://azul.rs/ framework (once I have text layout, regular layout and a software renderer running on no_std, there's nothing stopping Rust from being used for embedded GUIs).
This might not have been the intended use of this library, but I'm currently using it to estimate the script of user input, so that I can select the proper font shaping algorithm.
@fschutt Did you I get it right: you consider using whatlang to identify only script (writing system like Cyrillic, Latin, Arabic, etc) but not really languages?
If so, would it be better for you to be able to access only detect_script functionality without reset of that whatlang library (whatlang cares language trigrams models that are about 3-4Mb, and they are not needed for script detection).
If above is right, then maybe we should consider extracting detect_script functionality into a separate crate.
Well right now, I need to pass the language to allsorts gsub_apply function here:
You are right that this probably won't work on devices with low memory constraints (for those devices I could just pass in None as the language). For desktop applications it probably doesn't matter because they have enough memory.
Setting the lang attribute is required for using the langsys table on fonts, but it isn't strictly necessary.