The warning is that some of the variants are never read.
In the case of ftwrap, they are referenced via ffi.
For the other locations, we want them for debug purposes.
In https://github.com/wez/wezterm/issues/4877 it became clear that
the newer approach for finding fallback fonts is only better than
the old approach in some cases, so this commit adds a fallback
to the old approach if the new one didn't yield any usable results
for a given codepoint.
refs: #4099
Root cause is that font-config will try to find a single font that
satisfies a query like `fc-list ':charset=2686 3065'`, but if that
is impossible, there are no results.
The resolution is to split the query up and look for each individual
codepoint.
refs: #4310
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
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.
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.
When using the harfbuzz rasterizer with a bitmap glyph, the result
is a rasterized glyph that is pre-scaled to the cell dimensions.
We need to tell glyphcache that that has happened, otherwise it
will apply the same scale factor again.
I think I've got the right values going in and out, so I think
it's ok to turn this on, but I'm worried about legacy non-opentype
formats that freetype supports but harfbuzz doesn't.
Let's stick with ft's metrics until I find time to validate
the behavior.
This isn't fully baked, but it looks mostly ok.
The ghost emoji has a weirdly positioned white patch; there's
something funky with its positioning that needs to be investigated.
There's some copypasta here; a bunch of the cairo related stuff
was copied and adapted from the harfbuzz impl.
I plan to refactor the latter in terms of the former to reduce
the amount of code overall.
fixup colors and excessive clipping.
This now looks decent. Still don't support sweep gradients;
those look complex and I'm not sure that I have a font to
test that against.
This meshes well with the sequence of instructions that we
get from harfbuzz.
This will need some vendoring to integrate with wezterm's build
on all platforms; that can come later.
Still need to hook up gradients.
We need to make a couple of passes over the paint instructions,
and making a nice interface around FontFuncs and DrawFuncs was
taking up a lot of boilerplate.
Adjust so that we accumulate parsed PaintOps and DrawOps instead.
This makes the code smaller and easier to grok.
Still has trouble rasterizing the new noto color emoji font though.
I think this fixes up the discrepancy I had in metrics with images.
The "solution" is to tell harfbuzz to scale to the selected
bitmap strike size instead of the the computed pixel size for
the current settings.
