Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Center the square glyphs #2818

Open
boltlessengineer opened this issue Dec 1, 2022 · 2 comments
Open

Center the square glyphs #2818

boltlessengineer opened this issue Dec 1, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@boltlessengineer
Copy link

Problem describe

This issue covers a wider range of problems related to #2794.

Wezterm just prints nerd font icons on bottom-left. This makes square glyphs lean to left side and resized glyphs lean to bottom.

Desired outputs

When allowing width overflow

image

When glyph width is smaller than 2*cell_width, the glyph looks like it is lean to left side. It would be great if wezterm automatically gives x_offset to center the square glyph in 2-cell block.

When not allowing width overflow (previously described in #2794)

image

When not allowing width overflow, wezterm just scale the font down and align it to bottom. It would be better if wezterm vertically centers scaled fonts.

@wez
Copy link
Owner

wez commented Dec 2, 2022

Wezterm just prints nerd font icons on bottom-left.

No, that assumption is incorrect. Wezterm uses harfbuzz to correctly shape and compute placement information based on the metrics contained in the font program.

When working with font fallback, wezterm aligns the baselines of the fonts based on their metrics.

In general, wezterm doesn't know anything about the composition of a glyph; it only knows where to position the baseline vs. the bottom of the cell box and then asks harfbuzz to position it, and freetype to rasterize it. It may surprise you, but often the computed positioning metrics are for rectangles that are much smaller than the cell boundaries and often have x and y offsets that are not aligned to the cell corners or baseline.

Font metrics are very abstract and the interpretation of them varies from font family to font family; it is up to the font designer to decide how their glyphs fill up the EM-Square. That makes it especially difficult to reason about text alignment and placement between different fonts. You can read a bit more about this here: https://wezfurlong.org/wezterm/config/lua/wezterm/font_with_fallback.html#dealing-with-different-fallback-font-heights

I understand the nature of your request, but it is very difficult for an application to make the right kind of decision about overriding the information provided by the font program itself.

I'm willing to consider adding some options similar in nature to the scale parameter of wezterm.font_with_fallback that would allow the user to employ their own judgement on fine tuning the positioning for their particular set of fonts.

Also, FWIW: the nerd fonts have a history of shipping with somewhat mangled font metrics, so I do not want to hard code logic in wezterm based on observations made with bad font metrics.

@boltlessengineer
Copy link
Author

Thank you for your detail explanation.

wezterm doesn't know anything about the composition of a glyph

What do you mean composition? Doesn't wezterm knows about width and height of a glyph? I thought that was how allow_square_glyphs_to_overflow_width option works.

I do not want to hard code logic in wezterm based on observations made with bad font metrics

I don't know about Rust that much, but I don't think this would be a hard coding. Wezterm already seems to detect square glyphs and behaves differently for those glyphs (like allow_square_glyphs_to_overflow_width option). Can't we just add a little logic for modifying x and y offsets to center the glyphs if those are square glyphs?

I'm sorry if I misunderstood. My English skill is quite bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants