Misaligned Glyphs in Berkeley Mono

[amadeus]

Steps to reproduce

1. Using set guifont=BerkeleyMono-Regular:h16 as your font font link (can probably be repro'd with the existing trial
2. See attached screenshot comparing Vim in Ghostty terminal renderer vs MacVim:
   
3. The rounded corner graphics appear broken in MacVim

Expected behaviour

Unclear if the issue is because of how fallback fonts apply or if these are embedded glyphs in the font that are being mis-rendered

Version of Vim and architecture

MacVim 9.1, Included Patches: 1-727

Environment

Operating System: macOS Sequoia (15.0)

How MacVim was installed

Built from source

Logs and stack traces

No response

Vim configuration where issue is reproducable

No response

Issue has been tested with given configuration

• by running MacVim.app from GUI macOS interface
• by running vim/gvim/etc installed by MacVim
• by running other versions of vim (e.g. /usr/bin/vim)

Issue has been tested with no configuration

• by running mvim --clean (or gvim, supplied by MacVim distribution)
• by running vim --clean (in terminal, supplied by MacVim distribution)
• by running vim --clean (in terminal, other suppliers, e.g. /usr/bin/vim)

Other conditions

• The both Homebrew packages "vim" and "macvim" are installed

[ychin]

Thanks for the report. I can take a look. Btw have you tried this in the standard Apple terminal or text editor? (since I'm probably not going to install ghostty for this)

[serban]

Software	Version
macOS	14.7 Sonoma
MacVim	r180
iTerm2	3.5.6beta1
Kitty	0.36.4
WezTerm	20240203-110809-5046fc22
Terminal	2.14 (453)
TextEdit	1.19 (404)

I've had this problem in MacVim for as long as I can remember using the Monaco font that ships with macOS (though it does not present with the Menlo font that ships with macOS). Besides misalignment of rounded corners, there is also superfluous vertical spacing between box-drawing characters. Perhaps these issues are related.

See below for screenshots comparing the font rendering between various applications. → box-drawing.txt

A cursory look at iTerm2, Kitty, and WezTerm shows that they implement custom workarounds to fix these issues:

nexus ~/o/iTerm2 › master $ git --no-pager log --decorate=no --oneline --reverse --regexp-ignore-case --grep box.drawing
━━━━━━  2024-10-16 11:48:13  ━━━━━━
3834b2bf1 Add support for rendering box drawing characters with bezier paths so they connect properly
875a3e7c3 Use either pipe or unicode 0x2502 (box drawing light vertical), used by tmux, as dividers for selection wrapping
33462ba20 Use either pipe or unicode 0x2502 (box drawing light vertical), used by tmux, as dividers for selection wrapping
93da24715 Add support for ligatures. Rewrite drawing code to use only attributed strings for text. It's a little slower (mostly in constructing the attributed strings) but should fix a lot of bugs.
e953fc29d Try to speed up box drawing code. Issue 4971.
4a254fe21 Disable the zippy text drawing algorithm for cells that have combining marks or surrogate pairs. CG draws combining marks really badly; core text is slow but much better.
8ac04c1c6 Add arcs, diagonal lines, and X to box drawing. Issue 6076.
2b4ccebfe Add an advanced pref to disable custom box-drawing code. Issue 6151
a8171769b Add support for box drawing to Metal code path
a0fa69c3f Improve consistency of box drawing characters between legacy and GPU on nonretina displays. Issue 6851
d682f7e78 Update golden for box drawing to account for offset added in trying to improve nonretina rendering
076fc8621 Update travis version of box drawing golden
b10c08644 Fix cellSize/glyphSize mixup in box drawing characters (issue 6909). Also fix the background/foreground color, which was somehow still broken on Mojave
97e9cbbbf Fix some discrepancies in box drawing between metal and traditional. When vertical spacing was added the metal version was shifted up by half the shift. Also, retinaRound was wrong and was responsible for 1-pixel errors in Metal on retina displays. Issue 7152
48c848735 Fix drawing non-black box drawing characters in Mojave without subpixel AA. Issue 7275
41750c521 Update travis golden for box drawing. Looks funny in the test output because alpha<1 but in practice it looks fine.
bc48142e4 Add support for natively drawn powerline glyphs. This fixes two annoying things: minimum contrast is not applied to native box drawing glyphs, so now the powerline arrows look right next to the solid background color when minimum contrast is in use and; when you have extra vertical spacing everything lines up properly. Issue 7372.
2d9e9e76a Fix a bug where the gpu renderer didn't use minimum contrast if the preceding character was a box drawing character (or wrongly did use it when a box drawing characters follows a non-boxdrawing character)
daa6fb4a1 Add some performance improvements to the legacy renderer for box drawing. See email to list with subject line 'Major performance hit with truecolor'
754249556 Fix box drawing broken by daa6fb4a1
6e8a308d4 Fix vertical alignment of box-drawing characters when vertical spacing is enabled. Issue 7932
308258c74 Tweak box drawing characters to not be blurry in lowdpi. Issue 10791
5dc08fead Make minimum contrast apply to box drawing characters that are not block-like. Issue 6993
a196d3165 Don't try to center box-drawing characters vertically in GPU renderer. It leaves a gap for those that should be full-height. Issue 11478
f55b52a22 Fix discrepancy in box drawing characters gpu vs legacy. Issue 11577
1bffcc762 Log character source descriptor when drawing a box-drawing character
d051e014c Fix vertical alignment of box-drawing characters in the presence of vertical spacing. I think the problem was that the text renderer centers glyphs within their cell-including-spacing, which requires shifting glyphs by half the height of the extra spacing but that logic was not properly replicated in iTermCharacterSource. This commit carefully ensures we draw the glyph in exactly the rect that the text renderer expects it to be in. Issue 11478

nexus ~/o/kitty › master $ git --no-pager log --decorate=no --oneline --reverse --regexp-ignore-case --grep box.drawing
━━━━━━  2024-10-16 11:49:45  ━━━━━━
1b8197146 Start work on rendering box drawing characters directly
8424f5517 Finish the straight line box drawing characters
45d3e5a62 Render the corner box drawing chars
b1f180b22 T-junction box drawing characters
a645333b1 Make the box drawing corners smooth
3f91ae303 The half line box drawing characters
729b94fbe Cross box drawing chars
3e289a57f Better line sizes for box drawing
77a161bf1 Add the powerline block arrow symbols to the set of box drawing characters
82bc8cc89 Code to display all box drawing characters
f6000342b Some double line box drawing chars
a3a29b746 More box drawing characters
79f529c73 More box drawing chars
792aa694b Finish double line box drawing chars
8e565d5ab More box drawing chars
81143e0c7 Test to render all box drawing characters under the sanitizers
65b212fa1 Add a config option to control the line thickness for box drawing characters
4c94e1693 Refactor the box drawing showcase code
f77acdce1 remove useless import in help msg for box drawing debug
59cb1ad1e Implement special rendering for the diagonal line box drawing chars
576b03c04 Implement drawing thick anti-aliased lines
353db678a Add typing to box_drawing
e17c96b20 Improve anti-aliasing of triangular box drawing characters, noticeable on low-resolution screens
533688a67 Implement support for box drawing rounded-corners characters
a935c80ad Use box drawing for sextants
a50816126 Add smooth mosaic chars to box drawing
f32ad617a Special case rendering of the few remaining Powerline box drawing chars
4bcf69a47 Add more shade box drawing characters
576a26964 Special case rendering of some more box drawing characters using shades from the block of symbols for legacy computing
36c79f3d5 Implement box drawing for Fira Code progress bar glyphs in PUA
7d787e6c2 Implement box drawing for Fira Code spinner glyphs
3345e40bd Add some more box-drawing characters from the "Geometric shapes" Unicode block
f95768dce Add branch drawing symbols to box characters
48c7c538c Use box drawing for filled circle and fish eye so that they line up with empty circle

nexus ~/o/wezterm › main $ git --no-pager log --decorate=no --oneline --reverse --regexp-ignore-case --grep box.drawing
━━━━━━  2024-10-16 11:54:47  ━━━━━━
e0ea16167 Custom glyphs for box drawings solid and dashed lines
8a3fb1159 more box drawing glyphs
fad09eddd even more box drawing glyphs
843dd88bb improve box drawing rendering at smaller font sizes
0b5444ccf always use own box glyphs for pane splits
4e7f73fab box drawing: half lines and mixed lines
29f28885f box drawing: cell arcs
24fbba66c even more box drawing glyphs
b7f504b15 complete box drawing glyphs
e78696857 adjust hinting for box drawing

MacVim · Menlo

MacVim · Monaco

iTerm2 · Monaco

Kitty · Monaco

WezTerm · Monaco

Apple Terminal · Menlo

Apple Terminal · Monaco

Apple Terminal · SF Mono

TextEdit · Menlo

TextEdit · Monaco

[ychin]

Oh right this is the box drawing stuff. I missed that in the original issue report. Just to be clear, this is not really a "bug" per se and it's really a feature request. The misalignment is so because this is just how the font glyphs are defined and the terminals/MacVim that show rendering issues are just drawing the glyphs correctly. The terminals that display it "properly" are just manually overriding how to draw these symbols to match how old terminals used to work. Some fonts just happen to have better definitions for their box drawing characters (e.g. SF Mono) so just drawing the font works.

Vim itself had a request for this support for vanilla GVim in vim/vim#11477, where it was rejected by Bram (also see my comments which link to iTerm2/Alacritty discussions about this).

I don't fully agree with Bram's reasoning for closing it, as this has since become standard in a lot of modern terminals. I'll play around with this. We will need an option to turn this on or off and there is a design decision whether this should be an upstream GVim option or a MacVim user setting.

[ychin]

So, I have been playing around with this. The root cause for most issues in box drawing usually really have to do with the improperly designed fonts that have bad hinting for their glyphs, essentially making it a font bug. Unless we are dealing with non-standard line heights, it should be up to the font designer to make them all line up and match properly.

In @amadeus's example, the issue here is that the font didn't try to align the different box drawing characters leading to the corner being lower. Unfortunately, ghostty is not open source (but other terminals do have custom box drawing), and the font costs $75 (the trial version only has ASCII and doesn't have box drawing I think) so I don't have an easy way to look at them. For the example by @serban, it's true that Monaco does not draw these characters correctly but it's also a really old font that Apple has phased out a long time ago. The other fonts I tested mostly work fine.

Are there other examples of fonts that do not work properly and can be easily obtained/downloaded? My thinking is currently most terminals did add custom box drawing, so adding this is in a way adding feature parity, but philosophically I'm personally not a big fan of custom drawing because you essentially are going around the font design and not using the originally designed shapes for box drawing, and I imagine the original font designer died a little inside every time someone uses this custom feature. Even if I implement custom box drawing it would likely not be a default setting.

That said, It's easier if I could see more examples of fonts that don't work properly though, as that would give a little more context as to what exactly is wrong with them. (E.g. if it's a simple alignment issue that can be inferred from the glyph hints, that could be fixed easily)

There's still value to implementing custom drawing, if only for variable line heights (that the font cannot really account for), but if it's broken in every popular programmer font the priority would be higher than if it's a couple fonts here and there.