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

Not all emoji are working correctly #154

Open
D3vil0p3r opened this issue Feb 24, 2023 · 5 comments
Open

Not all emoji are working correctly #154

D3vil0p3r opened this issue Feb 24, 2023 · 5 comments
Assignees
Labels

Comments

@D3vil0p3r
Copy link

Hello, I'm using terminology with DroidSansMono font style and I note that the most of emojis are shown correctly while some emoji does not.

The emoji that is not shown correctly is the ⚔️ . How is it possible to fix it?

PS: I tested the font style also on other terminals (i.e., kitty) and ⚔️ is shown correctly. I have this issue only on terminology.

@borisfaure borisfaure self-assigned this Feb 24, 2023
@borisfaure
Copy link
Owner

Could you please take a screenshot so that I can see how it's not shown correctly?

@D3vil0p3r
Copy link
Author

Sure @borisfaure . As test, I put crossed swords emoji and also other working emoji on shell prompt, and also on the input field of the terminal.

On top of the image there is Terminology, on bottom there is Kitty terminal.

image

@borisfaure
Copy link
Owner

That's a very interesting bug.
The way terminology decides how wide a character should be displayed, is based on the unicode specification: 2 blocks when the codepoint (character) has a East Asian Width property set to Wide or Ambiguous. (see https://www.unicode.org/reports/tr11/ ) . This is done in termptydbl.c that I've just updated in c31d11d to support the latest unicode specification (15).

This codepoint is set as Neutral: https://codepoints.net/U+2694
I think this is a bug in unicode itself since I don't see why https://codepoints.net/U+2693 is set to Wide and not this one.

I tried to use the emoji property in the unicode specification to decide how large a codepoint should be displayed but it was even worse because some symbols can be rendered narrowly like ❤ despite having the emoji property (https://codepoints.net/U+2764).
I will probably let the user decide whether the emoji property is good way to know how large a codepoint must be rendered.

In terminology, I think you don't see an emoji for the ⚔ codepoint because you're not using the same font in Terminology and in Kitty. The font used in Terminology is able to render this codepoint and does not fallback to an other font. Could please test with the same fonts?

@D3vil0p3r
Copy link
Author

@borisfaure I did the test, I used on both of Kitty and Terminology the same font (JetBrains Mono (Medium)) and the result is the following (on top Kitty, on bottom Terminology):
image

@borisfaure borisfaure added the bug label Mar 17, 2023
@JosBosmans
Copy link

For extra screenshot's sake, this is foot and terminology displaying the same input with the same font (IBM Plex Mono).
hmh

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

No branches or pull requests

3 participants