Match out bold, semicondensed etc. from the full name.
Allow matching a font based on the full path to the font as
an alternative, because pcf fonts tend to have terrible
metadata and many pixel variants.
refs: https://github.com/wez/wezterm/issues/4256
Previously we'd use the scaled-by-line-height-and-cell-width dimensions
for the text cursor, leading to oddly dimensioned block cursors when
`line_height` or `cell_width` were configured.
This commit captures the native cell dimensions into the RenderMetrics
which makes it feasible for the glyph and sprite rendering logic to
reason about it.
The cursor rendering now renders at the native size and position by
using a transform to scale and translate into the correct spot.
We could potentially use the same technique for eg: braille or
other non-drawing characters
(https://github.com/wez/wezterm/issues/1957) although that is more
complex than just this commit.
refs: https://github.com/wez/wezterm/issues/2882
Previously we'd return the Url string. Now we provide a Url
object that provides access to the various elements of the Url.
This will cause slightly breakage for folks that were treating
it as a string in their status event handlers, for example.
The docs have been updated to show how to run with both this
new Url object and also continue to run on older versions of
wezterm.
They now also show how to manually percent decode the url
for older versions of wezterm.
refs: https://github.com/wez/wezterm/discussions/4157
refs: https://github.com/wez/wezterm/issues/4000
Move the shortcode aliases out from the various emoji category
pages and into a new shortcode page.
Add variations, such as skin tones, to the different emoji
category pages.
This gets the matching time down below 110+ms to around 70ms
in release mode, which may not sound like a huge amount, but 100ms
is on the cusp of perceivable latency, so getting below that is
desirable.
Freetype's support for colr is relatively rudimentary, which is fine,
but we want more control, so we probe a bit harder to figure out
whether a glyph has colr information before allowing freetype
to rasterize it, so that we have the opportunity to reroute
that rendering to our own logic.
Weirdly, the rust compiler is suddenly complaining about this,
when this file hasn't changed.
```
error[E0283]: type annotations needed
--> window\src\os\windows\window.rs:2398:26
|
2398 | if vk <= u8::MAX.into() {
| -- ^^^^
| |
| type must be known at this point
|
= note: cannot satisfy `u32: PartialOrd<_>`
help: try using a fully qualified path to specify the expected types
|
2398 | if vk <= <u8 as Into<T>>::into(u8::MAX) {
| ++++++++++++++++++++++ ~
error[E0283]: type annotations needed
--> window\src\os\windows\window.rs:2415:32
|
2415 | if leader.1 <= u8::MAX.into() && key.1 <= u8::MAX.into() {
| -- ^^^^
| |
| type must be known at this point
|
= note: cannot satisfy `u32: PartialOrd<_>`
help: try using a fully qualified path to specify the expected types
|
2415 | if leader.1 <= <u8 as Into<T>>::into(u8::MAX) && key.1 <= u8::MAX.into() {
| ++++++++++++++++++++++ ~
```
Now we can optionally skip loading svg fonts, making our default
to continue to try to use them.
We don't actually support interpreting svg data, but we do now
support COLR v1 data which is found in some of those same fonts.
refs: https://github.com/wez/wezterm/issues/4148
The harfbuzz driven rasterization of COLR glyphs is superior to
my attept at a freetype driven rasterizer, so let's default to
the harfbuzz version.
This change means that the default for most regular glyphs is
freetype, but we'll use harfbuzz for COLR glyphs.
Popping open the char selector could result in comedy-sized emoji
that dramatically overflow the bounds.
The reason for that is that glyphcache isn't smart enough to notice
when the glyph.height exceeds the cell_height and allows the glyph
bitmap to be rendered at the rasterized size.
The reason for that glyph being so huge is that freetype is producing
outlines that are too large. The font metrics have the requested
x and y ppem values (eg: the nominal font size in pixels), but also
x and y scaling values that are not set to 1. The result is that
the produced extents are too large by those x and y scaling values.
I'm not sure why that is, but it is simplest and most self-contained
to adjust for that scale factor when we rasterize via cairo, so that
is what we do here.
