Exclude development scripts from published packages (#80) During a dependency review we noticed that the unicode-width crate includes various development scripts. These development scripts shouldn't be there as they might, at some point become problematic. As of now they prevent any downstream user from enabling the `[bans.build.interpreted]` option of cargo deny. I opted for using an explicit include list instead of an exclude list to prevent these files from beeing included in the published packages to make sure that everything that's included is an conscious choice.
unicode-widthDetermine displayed width of char and str types according to Unicode Standard Annex #11 and other portions of the Unicode standard.
This crate is #![no_std].
use unicode_width::UnicodeWidthStr; fn main() { let teststr = "Hello, world!"; let width = teststr.width(); println!("{}", teststr); println!("The above string is {} columns wide.", width); let width = teststr.width_cjk(); println!("The above string is {} columns wide (CJK).", width); }
NOTE: The computed width values may not match the actual rendered column width. For example, many Brahmic scripts like Devanagari have complex rendering rules which this crate does not currently handle (and will never fully handle, because the exact rendering depends on the font):
extern crate unicode_width; use unicode_width::UnicodeWidthStr; fn main() { assert_eq!("क".width(), 1); // Devanagari letter Ka assert_eq!("ष".width(), 1); // Devanagari letter Ssa assert_eq!("क्ष".width(), 2); // Ka + Virama + Ssa }
Additionally, defective combining character sequences and nonstandard Korean jamo sequences may be rendered with a different width than what this crate says. (This is not an exhaustive list.) For a list of what this crate does handle, see docs.rs.
You can use this package in your project by adding the following to your Cargo.toml:
[dependencies] unicode-width = "0.2"
\n as width 1 (#60)Modifier_Letters as narrow (#63)Grapheme_Cluster_Break=Prepend (#62)Note: If you are using unicode-width for linebreaking, the change treating \n as width 1 may cause behavior changes. It is recommended that in such cases you feed already-line segmented text to unicode-width. In other words, please apply higher level control character based line breaking protocols before feeding text to unicode-width. Relying on any character producing a stable width in this crate is likely the sign of a bug.