Allows for high dpi displays to get odd numbered pixel sizes, for
example, 13.5pt @ 2px/pt for 27px font. This implementation performs
all the sizing calculations with f32, rounding to the nearest pixel
size when it comes to rendering. In the future this can be enhanced
by adding fractional scaling to support fractional pixel sizes.
Now that we're padding the cells with blanks if we have shaped ligatures
we don't actually know the exact count based on the CoreText APIs, so we
should just dynamically add.
We previously split text runs for shaping on bg color changes. As
pointed out in Discord, this is not necessary, since we can always color
cells according to their desired background even if the text in the cell
shapes to something else.
Fixes#1708
Harfbuzz does this automatically. Our tests for harfbuzz test this. We
had a todo in CoreText to mimic this but wasn't sure if it was useful.
Turns out, it is important (see bug!)
Key contains pointers into DerivedConfig. Each surface has its own
DerivedConfig. This would cause memory corruption if the surface that
opened the initial font grid deallocates. Instead, let's make sure Key
owns its own DerivedConfig.
Fixes#1670
This fixes two issues:
- If no font families are set, font points would not change the hash.
- DPI changes would not change the hash.
When the hash doesn't change when it should, we reuse a font stack due
to changes in #1662. This would cause some font issues. :)
Fixes#1664
I previously asserted that we got exactly one run from CoreText because
I assumed that our run iterator was perfectly splitting runs for
CoreText. This assumption appears to be false and that seems okay.
The test case in this commit produces two runs that are directly next to
each other and there's no downside to simply iterating over them. So
this commit changes to iterate over the runs.
