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.
I'm experimenting with using cairo's 2D graphics for glyph related
drawing operations, and perhaps more stuff in the UI in the future.
The challenge is that no one has yet encapsulated its build in a
cargo-friendly way.
This commit is that attempt.
The strategy is this:
* `deps/cairo` is ostensibly the same thing as https://github.com/gtk-rs/gtk-rs-core/tree/master/cairo/sys
which is the cairo-sys-rs crate
* Its build.rs has been replaced with a version that builds from the C
sources that are found in-tree; it will never look for the system
cairo library
* A pair of scripts to import pixman (a required dep of cairo) and
cairo itself in a repeatable way are include, for if/when we need
to update the vendored sources
Cairo is a mature library and doesn't release very often.
* The workspace sets a patch for crates.io so that cairo-rs has
its cairo-sys-rs dep redirected to the local build.
I'm not planning to upstream this stuff to gtk-rs-core as full cairo
depends on a lot more things than are dealt with here, so it would be a
PITA to handle that generally.
This vendoring strips out things that are not used, so the cairo
library that remains:
* Is not internally thread safe; no TLS or mutex support is enabled
in either of them. That's fine because the high level cairo-rs
wrapper is not Send+Sync, which means that rust will only allow
it to be used single threaded anyway.
* Only has the basic recording and image surfaces
* No platform support for win32/xlib/xcb and so on
* Allow set_environment_variables to set the SHELL.
Previously, we'd always set it to the shell from the password
database. Now we do that by default, but if set_environment_variables
has been used, we'll preserve that value for the environment
of the to-be-spawned process
* Clarify the docs:
* Remove the confusing version dependent sections that started
with old behavior and rewrite in terms of the behavior that
has been true for the past year
* I've heard from a few people that they tried to change COMSPEC
on Windows and pain ensued. Try to nudge them to read the
next paragraph that tells them what they are actually supposed
to change.
refs: https://github.com/wez/wezterm/issues/4098
refs: https://github.com/wez/wezterm/issues/4168
closes: https://github.com/wez/wezterm/issues/3816
refs: https://github.com/wez/wezterm/issues/3317
The vertical alignment is wonky, and some glyphs have the wrong
aspect and are missig colors. eg: the watermelon glyph in Noto Color
Emoji (U+1f349).
Turn this off by default, and skip loading fonts that have svg by
default.
The warnings were not noticed in the original PR.
Those warnings were actually errors.
Promote warnings to error in the mapping logic to prevent
this sort of thing from slipping through in the future,
and fixup the errors.
refs: #3935
refs: #3937
Note that this also does not respect dpi_by_screen; this is for
consistency in behavior and reported values.
Once we can produce the correct overridden value in
dispatch_pending_event, we can update these functions to return
the same data.
refs: #4096
This is a baby step towards handling dpi_by_screen.
I don't want to do the actualy per-screen stuff here;
it touches stuff around the edges of SCTK and there is a pending,
significant, rewrite of that code needed to upgrade to a more
recent version of SCTK + wayland-protocols, and I don't want to waste
my effort on the intermediate state.
https://github.com/wez/wezterm/issues/3996#issuecomment-1636830740
refs: #4096
Maintain a cache of the positions of the various named screens,
and use that to resolve the screen of the current window, and
from there we can resolve the correct dpi_by_screen screen.
Make dpi and dpi_by_screen config changes generate a resize
event with the updated dpi.
refs: #4096
Allows specifying the precise dpi to use on a per-screen basis:
```lua
return {
dpi_by_screen = {
["Built-in Retina Display"] = 144,
},
}
```
The screen names are the same as those returned from
`wezterm.gui.screens()`.
Changing either `dpi` or `dpi_by_screen` in the config will now cause
the window to be immediately resized/adjusted to the changed dpi
override.
Ultimately, I'd like to deprecate `dpi` in favor of `dpi_by_screen`,
but can't do that until this functionality is ported to windows, x11
and wayland.
refs: #4096
The approach we were using previously was to ask macOS for the fallback
font list, but it didn't include the correct fonts for certain
codepoints.
Switch to using an alternative API that asks macOS which font to use for
a specific codepoint.
refs: #4099
