Provides pre-rasterized characters from the "Noto Sans Mono" font in different sizes and font
weights for multiple unicode ranges. This crate is no_std and needs no allocations or floating
point operations. Useful in kernels and bootloaders when only "soft-float" is available. Strictly
speaking, this crate is more than a basic bitmap font, because it encodes each pixel as a byte
and not as a bit, which results in a much nicer result on the screen.
no_std, zero allocations, no floating point operations
Legacy (8x8) bitmap fonts usually refer to a font where each symbol is encoded in 8 bits. The ones in a byte
(0b00110000) means "pixel on" and the zeroes' means "pixel off". However, my font actually encodes the
intensity of each pixel as a byte from 0 to 255. Hence, this is less size efficient than legacy bitmap fonts,
but looks much better. I still use the term bitmap font, because that term is used and known when talking
about pre-rasterized fonts/font rendering in low-level contexts, such as the boot process.
If you want to print to a framebuffer and if you develop a bootloader or a kernel, you usually don't
want to enable the FPU and refrain from floating point instruction (i.e. only use soft float).
My crate is a good option to print characters nicely to the screen in such scenarios. As nice live
font rendering of TTF fonts heavily relies on many floating point operations, which is not optimal
inside a low level binary. Legacy 8x8 bitmap fonts are ugly when printed to the screen.
noto_sans_mono_bitmap can be seen as a nice replacement with very nice anti-aliasing.
If you have a standard environment or support for floating point operations, you might want
to rasterize the font by yourself with the crate fontdue and some TTF fonts rather than
using my crate.
```rust use notosansmonobitmap::{getraster, getrasterwidth, FontWeight, RasterHeight};
// Minimal example. fn main() { let width = getrasterwidth(FontWeight::Regular, RasterHeight::Size16); println!( "Each char of the mono-spaced font will be {}px in width if the font \ weight={:?} and the bitmap height={}", width, FontWeight::Regular, RasterHeight::Size16.val() ); let charraster = getraster('A', FontWeight::Regular, RasterHeight::Size16).expect("unsupported char"); println!("{:?}", charraster); for (rowi, row) in charraster.bitmap().iter().enumerate() { for (coli, pixel) in row.iter().enumerate() { println!("[{:02}][{:02}]: {:03}", rowi, coli, pixel); } } } ```
By default, only a reasonable subset of possible features is included. The raw crate-size is a few MiB in size but after compilation and discarding irrelevant parts (i.e., size 14, regular font, only ASCII), the overhead should be at less than 120 KiB in binary size, according to my measurements. The compiler can reliably discard unused sizes or weights, but not so for unicode ranges. Thus, it is recommended to include no more features than necessary.
With all features included inside the binary, and without any discarding by the compiler, you can expect 5 or more MiB of memory requirements. However, this would require the rather unlikely case that you use different sizes and font weights simultaneously.
For a full support of all unicode ranges, use an on-the-fly rasterization process instead of this crate.
$ cargo run --example show_chars_in_window
Because the examples uses minifb as dependency, on Linux the package libxkbcommon-dev is required
to run them. This is not necessary, if you just use this crate as dependency.
The rasterization was done with the awesome fontdue-Crate. Thanks to the original author(s)!
See LICENSE file in repository.
Rust stable 1.52.1.