Closed zeorin closed 1 year ago
kovidgoyal
commented
1 year ago Dont do that. Absolutely never mess with unicode codepoint widths. Doing that means any program running in the terminal now has absolutely no way to know what width a string has.
zeorin
commented
1 year ago Do programs make these assumptions? The standard says that the default presentation style of these codepoints is effectively up to the environment. https://www.unicode.org/reports/tr51/#Emoji_vs_Text_Display
Even if programs make those assumptions, shouldn't users still be able to control the default presentation? Obviously, for characters like *#0123456789, changing their default presentation is foolhardy (they were included in this bug report for completeness' sake).
Regardless of the wisdom of what I'm doing, I'm asking kitty to use a specific font for specific code points, in a way that the standard allows for, and kitty silently makes some of those characters invisible, it doesn't fall back to a text representation, nor does it log an error or a warning.
I think that regardless of one's opinion about whether you want to allow a user to set the default presentation of these codepoints explicitly, the current behaviour is still a bug, at least ito the lack of feedback or fallback.
kovidgoyal
commented
1 year ago On Wed, Aug 23, 2023 at 11:40:16PM -0700, Xandor Schiefer wrote:
Do programs make these assumptions? The standard says that the default presentation style of these codepoints is effectively up to the environment.https://www.unicode.org/reports/tr51/#Emoji_vs_Text_Display
I would not have said that they do if they didnt, now would I? And even a moments thought about the issue would lead one to conclude that they have to. There are two independent players that need to compute the width of the string and arrive at the same answer. The terminal program and the terminal emulator. The only way that can happen is if both use the same assumptions/standards.
Even if programs make those assumptions, shouldn't users still be able to control the default presentation? Obviously, for characters like
*#0123456789, changing their default presentation is foolhardy (they were included in this bug report for completeness' sake).
No, because now you have made it impossible for the two parties above to agree on widths.
Regardless of the wisdom of what I'm doing, I'm asking kitty to use a specific font for specific code points, in a way that the standard allows for, and kitty silently makes some of those characters invisible, it doesn't fall back to a text representation, nor does it log an error or a warning.
The standard does not allow for it.
I think that regardless of one's opinion about whether you want to allow a user to set the default presentation of these codepoints explicitly, the current behaviour is still a bug, at least ito the lack of feedback or fallback.
Sure, except that what you are doing will break things and therefore is not a supported use case and not one I want to spend time adding extra error handling for. Patches welcome.
zeorin
commented
1 year ago How would you feel about a patch that picks a presentation of these code points depending on whether they're directly followed by whitespace or not?
kovidgoyal
commented
1 year ago What's the use case? Rather than using spaces which would allow only for making text presentation into emoji rather than the other way around, use the variation selectors, that allow you to do both.
zeorin
commented
1 year ago I prefer emoji presentations, where possible, as they are often easier to read, especially at lower font sizes. But, I'm not necessarily in control of the codepoints that are emitted by programs.
Your point about a program not having any way to know how many cells a terminal emulator will use to render a glyph, and thus needing to assume the default presentation's cell width, is indeed a very good point.
However, it is common to display some glyphs a little bit bigger than a single cell if there is sufficient space to do so, typically when the character is succeeded by a space. Even kitty itself already does this for certain glyphs:
When separated by non-breaking spaces, the text characters all use only one cell to render:
When separated by normal spaces, some text characters are rendered larger, they're allowed to bleed into the following cell:
I would like to be able to tell kitty to render some of these code points as emoji if they are followed by a space. And/or, being able force the emoji representation regardless of whether the character is followed by a space, but just rendering it smaller when it is not followed by a space; though I'm not as sure of the benefit of this, they might be rendered too small to be worth it.
kovidgoyal
commented
1 year ago But if you are not in control of the output from the programs, how are you going to insert the needed spaces? The issue here is that if kitty changes how characters are rendered in ways outside the standard then programs can no longer rely on that rendering. Admittedly, if the width isn't changed, the consequences are not too severe, but they are still present. For instance, text mode characters are rendered using the foreground color, emojis are not. A program could conceivably rely on a character being rendered in the foreground color.
zeorin
commented
1 year ago But if you are not in control of the output from the programs, how are you going to insert the needed spaces?
I'm not going to be able to insert such spaces in most cases. However, because of the aforementioned current behaviour of some of the codepoints which default to text representation being displayed larger if there is a space following them, in some cases the programs do emit a space following the character specifically for that reason.
Even if a programmer may not have added the space specifically for that reason, since the characters in question are pictographs and not letters, they are usually not emitted next to non-space characters anyway.
The issue here is that if kitty changes how characters are rendered in ways outside the standard then programs can no longer rely on that rendering.
For some of these characters, the rendering is already dependent on whether or not they're followed by a space. Their rendered width is already variable. This is, in principle, not new behaviour, at least as far as rendered widths are concerned.
Even for characters whose text presentation is not rendered larger when followed by a space, if I was able to render them as emoji when they're followed by a space, this is very unlikely to cause an issue with the proper functioning or rendering of any program, because the emoji is being rendered into its original characters' cell and the following space's cell. No other cells would be affected in any way.
At worst, perhaps for some programs some of the emoji might end up looking more crowded by neighbouring characters than the program author intended, but it breaks none of the assumptions they would have made about which other glyphs would have been rendered where, as the overall cell grid is not affected.
I do think this should be opt-in functionality, for specific code points that the user can specify, not for all of them (especially since *#1234567890 are part of this set of codepoints). Given the ability to be able to programmatically change kitty's settings at runtime, it's even possible for a user to wrap programs in a shell script that enables / disables this functionality for specific code points if they wish, effectively allowing one to use a specific "emoji presentation map" for some programs.
Admittedly, if the width isn't changed, the consequences are not too severe, but they are still present. For instance, text mode characters are rendered using the foreground color, emojis are not. A program could conceivably rely on a character being rendered in the foreground color.
Yes, that is true. But given that the user would opt in to this behaviour, that is the trade-off that they're making. But, they'd be able to choose which code points behaved this way, and with some shell scripting they could even customise this for some programs.
When combined with symbol_map, they could even choose different emoji fonts for different characters, which might also be a way to work around some of those issues; some emoji fonts use very flat designs, but others don't, which affects how much a glyph might e.g. "fade into the background" if its color is similar to the background color; emoji fonts sometimes also have rather different pictograms for some code points, e.g. "🫖 Teapot".
kovidgoyal
commented
1 year ago On Thu, Aug 24, 2023 at 04:32:49AM -0700, Xandor Schiefer wrote:
But if you are not in control of the output from the programs, how are you going to insert the needed spaces?
I'm not going to be able to insert such spaces in most cases. However, because of the aforementioned current behaviour of some of the codepoints which default to text representation being displayed larger if there is a space following them, in some cases the programs do emit a space following the character specifically for that reason.
Converting a text mode character into a emoji is not a behavior that should be relied on. If a programmer wants emoji presentation they should ask for it. Perpetuating this hack is just bad for the ecosystem.
Even if a programmer may not have added the space specifically for that reason, since the characters in question are pictographs and not letters, they are usually not emitted next to non-space characters anyway.
Either the programmer wanted text mode or was not aware of the two modes at all. In either case you are hacking around their intentions which can break things. Now everyone everywhere has to be aware that how their unicode codepoints are rendered is dependent on whether they are followed by a space or not.
The issue here is that if kitty changes how characters are rendered in ways outside the standard then programs can no longer rely on that rendering.
For some of these characters, the rendering is already dependent on whether or not they're followed by a space. Their rendered width is already variable. This is, in principle, not new behaviour, at least as far as rendered widths are concerned.
kitty has variable rendered width only for PUA characters (which have no defined appearance) and some dingbats. It does not change the type of character only the amount of width it is rendered in. That is not the same as changing the type of a character from text to emoji or vice versa. Text and emoji characters have very different semantics when it comes to foreground colors.
Even for characters whose text presentation is not rendered larger when followed by a space, if I was able to render them as emoji when they're followed by a space, this is very unlikely to cause an issue with the proper functioning or rendering of any program, because the emoji is being rendered into its original characters' cell and the following space's cell. No other cells would be affected in any way.
background = white foreground = black. text mode character rendered as black. emoji happens to be mostly white => rendered invisible or indistinguishable.
At worst, perhaps for some programs some of the emoji might end up looking more crowded by neighbouring characters than the program author intended, but it breaks none of the assumptions they would have made about which other glyphs would have been rendered where, as the overall cell grid is not affected.
I do think this should be opt-in functionality, for specific code points that the user can specify, not for all of them (especially since
*#1234567890are part of this set of codepoints). Given the ability to be able to programmatically change kitty's settings at runtime, it's even possible for a user to wrap programs in a shell script that enables / disables this functionality for specific code points if they wish, effectively allowing one to use a "emoji map" for some programs.
Your opt in functionality makes it impossible to rely on the nature of characters for people trying to write terminal programs. I have again and again refused to implement such options in kitty. See bold-as-bright or overriding fonts for box drawing, braille and related symbols.
I have been struggling for years to introduce some thoughtful design and coherence into this space which is basically a tower of half thought out hacks upon half thought out hacks.
Ordinarily I am all in favor of allowing users to customise things, but not at the expense of making it impossible to write robust terminal programs.
Admittedly, if the width isn't changed, the consequences are not too severe, but they are still present. For instance, text mode characters are rendered using the foreground color, emojis are not. A program could conceivably rely on a character being rendered in the foreground color.
Yes, that is true. But given that the user would opt in to this behaviour, that is the trade-off that they're making. But, they'd be able to choose which code points behaved this way, and with some shell scripting they could even customise this for some programs.
When combined with
symbol_map, they could even choose different emoji fonts for different characters, which might also be a way to work around some of those issues; some emoji fonts use very flat designs, but others don't, which affects how much a glyph might e.g. "fade into the background" if its color is similar to the background color; emoji fonts sometimes also have rather different pictograms for some code points, e.g. "🫖 Teapot".
Sorry, but I am not convinced.
zeorin
commented
1 year ago OK. I appreciate the attention you gave this issue. Thanks for all the work you do.
Describe the bug Setting
symbol_mapfor codepoints with text and emoji presentations to an emoji font does not work for all the codepoints.I'm trying to get kitty to render all codepoints in https://www.unicode.org/Public/15.0.0/ucd/emoji/emoji-variation-sequences.txt, when not suffixed with either VS15 (
U+FE0E) or VS16 (U+FE0F), as emoji.I would expect all these code points to be rendered as emoji when using
symbol_mapto render them with Noto Color Emoji. Noto Color Emoji has glyphs for all of them.Instead, some code points are not rendered at all. The ones that aren't rendered are ones that would be rendered as text by default. The ones that are rendered are ones that are rendered as emoji by default.
If I choose a regular font for the symbol map instead, the codepoints that are rendered as emoji by default are instead rendered as tofu, which makes sense, since that font does not have glyphs for them.
To Reproduce
Screenshots
For reference, here are two screenshots of these exact same codepoints (copy-pasted from kitty itself) being rendered in LibreOffice Writer.
Using DejaVu Sans Mono:
Using Noto Color Emoji (this is what I expected from kitty):
Environment details
Additional context
Adding
--debug-font-fallbackdoes not seem to yield any clues: