- Fix string formatting with modern interpolation syntax
- Improve Debug implementation with finish_non_exhaustive()
- Fix function placement in shape.rs to avoid items_after_statements warning
- Use more idiomatic Rust patterns (map_or_else, next_back)
- Clean up conditional imports in vi.rs
- Convert multiple methods to `const` functions for optimization and consistency
- Introduce `core_maths` for enhanced no-std compatibility
- Update `Cargo.toml` for the new optional dependency and feature adjustments
- Skip expensive grapheme iteration for simple ASCII words
- 32% performance improvement for code-like text
- 5-7% improvement for general ASCII content
- No regressions for Unicode text processing
- Conservative ASCII detection maintains correctness
* Variable font support
Here's a pretty naïve solution for variable fonts.
The iterator doesn't use the match keys' weight, but instead tries to
get the requested ideal weight, if the font is variable, otherwise it is
ignored and the actual (non-variable) weight is used. This is because I
didn't implement finding variable weight support for match keys; doing
so would be impossible without parsing TTF files when matching and I
didn't want to add that potentially expensive infrastructure if not
entirely necessary.
This is a breaking change, and I'm open for ideas on how to fix that
if it's an issue.
* cargo fmt
* Add variable font example to rich-text example
We want byte indices, not code point indices. Fixes a panic when
selecting the mixed-language text at the bottom of the rich-text example
when the shaping mode is set to "Basic".
The ShapePlanCache was added to improve performance when shaping the same
strings over and over. However, it never had the ability to be trimmed
and when it was moved to FontSystem, this created a permanently growing
allocation. It is recommended to instead use the shape-run-cache feature
which supports trimming if it is desired to have higher performance for
repeated shaping, at the cost of manually specifying when to trim.
This should/could improve fallback order.
This could also probably be utilized for non-Monospace fallback too.
But I didn't want to touch that code to avoid accidentally breaking
anything.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
When matching to a default monospace width, big fonts like those
containing symbols and emojis got too small from font resizing.
Adding a glyph-to-default rounded factor to the calculation should fix
that issue without losing monospatiality.
Fixespop-os/cosmic-term#69.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
A combination of some ideas:
* Try all Monospace fonts before giving up.
* Relax exact weight restriction on font matching when trying Monospace
fall-back. Try smaller weights if needed.
* Make the fall-back try order weight-offset aware, AND script-aware.
* And finally, add the option to adjust the font size of glyphs using
fall-back Monospace fonts, so the width of them matches the default
font width.
For my use-case, the current fall-back attempt always fails with
Arabic script. And none of the Arabic-supporting Monospace fonts in
my system also support medium weight. So, if my default font is set
to medium weight, script-aware fall-back alone will still not work.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
