wezterm icon indicating copy to clipboard operation
wezterm copied to clipboard

Unexpected transformed braille when increasing or decreasing line_height

Open kumattau opened this issue 3 years ago • 4 comments

What Operating System(s) are you seeing this problem on?

Linux X11

WezTerm version

20220507-145508-b365cdbb

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

The braille (0x2800..=0x28ff) is transformed unexpectedly when increasing or decreasing line_height.

I think the braille should not be transformed corresponding to line_height because the braille is normal character unlike box drawing.

To Reproduce

increase or decrease line_height

Configuration

local wezterm = require 'wezterm'; return { line_height = 5.0, }

Expected Behavior

The braille does not transformed corresponding to line_height.

Logs

No response

Anything else?

No response

kumattau avatar May 08 '22 02:05 kumattau

You can set custom_block_glyphs = false to avoid this behavior. https://wezfurlong.org/wezterm/config/lua/config/custom_block_glyphs.html

Braille glyphs are custom rendered to make programs using them as a drawing board beautiful, instead of having irregular blanks between them as the glyphs from the font are not usually exactly the size of a cell.

bew avatar May 08 '22 10:05 bew

You can set custom_block_glyphs = false to avoid this behavior. https://wezfurlong.org/wezterm/config/lua/config/custom_block_glyphs.html

Braille glyphs are custom rendered to make programs using them as a drawing board beautiful, instead of having irregular blanks between them as the glyphs from the font are not usually exactly the size of a cell.

Thank you for information. I had never heard of Braille Art before. Indeed, for this purpose, current braille drawing may be as expected.

But when braille makes to be rendered as normal character, the drawing result is not desirable. custom_block_glyphs = false may not be able to used in this situation because it also affects box drawing. I think more fine control than custom_block_glyphs = false is needed.

kumattau avatar May 08 '22 10:05 kumattau

In this case I'm thinking custom_block_glyphs could be converted to a string representing the different unicode ranges? Something like custom_block_glyphs = "BoxDrawing|BlockElements|SymbolsForLegacyComputing|Braille|Powerline" would be the default (maybe even make a new config, custom_glyphs and deprecate the other one, since it's not only for blocks anymore)

@wez what do you think?

bew avatar May 08 '22 11:05 bew

@bew: yeah, I think adding a custom_glyphs config that uses bitflags to control which ranges are covered like we do for LauncherFlags: https://github.com/wez/wezterm/blob/736169a7526c1acf93edd4c1d5f12feaf6177310/config/src/keyassignment.rs#L18-L96 would make sense.

da7da888cdb633a78ede71455fad9e9f60f08a96 will allow annotating the custom_block_glyphs option like this:

    #[dynamic(deprecated = "use custom_glyphs instead", default = "default_true")]
    pub custom_block_glyphs: bool,

I'll happily accept a PR to implement the custom glyphs bitflags change :-)

wez avatar May 21 '22 20:05 wez