1
1
mirror of https://github.com/wez/wezterm.git synced 2024-11-23 23:21:08 +03:00
Commit Graph

6 Commits

Author SHA1 Message Date
Wez Furlong
850163ed11 test-data: add text from #614 to width script 2021-05-01 19:50:31 -07:00
Wez Furlong
8880979586 Adjust font scaling math again
This commit introduces the knowledge about whether a font is
scalable or was using bitmap strikes (eg: color emoji bitmaps).

Then that information is used to help figure out whether and
how to scale a glyph.

refs: https://github.com/wez/wezterm/issues/685
2021-05-01 16:45:57 -07:00
Wez Furlong
67de3f2235 Add underline test script 2021-04-30 09:20:08 -07:00
Wez Furlong
1b12b0a23d fonts: improve font_rules behavior
We now always append the synthetic rules to the those in the config,
and include rules for generating half-bright font selection.
2021-04-15 09:43:24 -07:00
Wez Furlong
0597684ebd Render custom block glyphs
As explained in the docs included in this commit, ideally this
wouldn't be needed, but due to a long-standing hinting bug in
freetype <https://gitlab.freedesktop.org/freetype/freetype/-/issues/761>
it seems most expedient to just render our own block glyphs,
so that's what this does!

refs: #433
2021-02-28 09:43:26 -08:00
Wez Furlong
a063d20cf0 wezterm: improve shaping of emoji
This is one of those massive time sinks that I almost regret...
As part of recent changes to dust-off the allsorts shaper, I noticed
that the harfbuzz shaper wasn't shaping as well as the allsorts one.

This commit:

* Adds emoji-test.txt, a text file you can `cat` to see how well
  the emoji are shaped and rendered.

* Fixes (or at least, improves) the column width calculation for
  combining sequences such as "deaf man" which was previously calculated
  at 3 cells in width when it should have just been 2 cells wide, which
  resulted in a weird "prismatic" effect during rendering where the
  glyph would be rendered with an extra RHS portion of the glyph across
  3 cells.

* Improved/simplified the clustering logic used to compute fallbacks.
  Previously we could end up with some wonky/disjoint sequence of
  undefined glyphs which wouldn't be successfully resolved from a
  fallback font.  We now make a better effort to consolidate runs of
  undefined glyphs for fallback.

* For sequences such as "woman with veil: dark skin tone" that occupy a
  single cell, the shaper may return 3 clusters with 3 glyphs in the
  case that the font doesn't fully support this grapheme.  At render
  time we'd just take the last glyph from that sequence and render it,
  resulting in eg: a female symbol in this particular case.  It is
  generally a bit more useful to show the first glyph in the sequence
  (eg: person with veil) rather than the gender or skin tone, so the
  renderer now checks for this kind of overlapping sequence and renders
  only the first glyph from the sequence.
2020-11-23 13:45:38 -08:00