We were panicking when rendering the || ligature, which is narrower
than we were expecting. There was also a weird looking assert
that was triggering if we got path the math overflow.
I wasn't pleased with how text was rendering on a colored background,
and after some research I discovered that I was neglecting to convert
from sRGB to a linear RGB colorspace, and that this was causing the
blending to have inaccurate results.
This diff pulls in the palette crate to handle the heavy lifting.
It doesn't appear to have any especially fast optimizations for this
though, which is a shame because the blending code I was using
previously was largely integer math with few branches. The colorspace
conversion has several floating point operations and branches that
are unavoidable :-/
We run a bit hotter on the CPU but the results are much more pleasing
to the eye.
This is most noticable with a cursive italic font. When we
were dividing the glyph into cell slices, we could leave off
a 2 pixel wide strip from the last of the sequence and this
looked nasty.
This diff also adjusts come calculations to use the width and
height from the current TextStyle. Whether this is more or
less correct remains to be seen :-p
This enables selecting an italic font when the cell is italic,
but has more power beyond just that simple property.
This runs a little hot on the CPU so there's probably some caching and
tweaking that can be done to make the evaluation a bit cheaper.
So that we no longer assume Operator Mono SSm.
We now default to `monospace`. I just tried this and the font metrics
appear to be wonky, so there's some tweaking to do.
We weren't quite right with handling the cursor around double-width
characters. We're now a bit more robust at this because we're
clustering and taking pains to consider the printable width of the
cell as well as the width of the shaped (eg: with contextual ligatures)
glyph.
There may still be issues with contextual ligatures of length 3,
but I haven't managed to nail down exactly the issue yet.
