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

Handling of Emoji without a Text or Graphical Selector on Linux and macOS #1053

Open
chubin opened this issue Jan 22, 2025 · 5 comments
Open

Comments

@chubin
Copy link
Owner

chubin commented Jan 22, 2025

(follow up to the discussion: ghostty-org/ghostty#4921)

Find a good way to configure the types of emojis to be used for weather
conditions so that they are displayed properly in different terminals with
different fonts configured.

/cc @mwolson

See also

@chubin
Copy link
Owner Author

chubin commented Jan 22, 2025

@mwolson

What is your opinion on how we should approach this issue?

The most obvious solution is to pass an option that specifies which emojis should be used.

curl wttr.in/?format=2&symbols=xxx
  1. What do you think about this approach?
  2. What is the best option name for this?
  3. What values should be used for it?

Another problem, which is quite similar, is the width of the emoji line in the v2 view (v2.wttr.in), though probably this option will not be sufficient to solve that problem for all terminals.

@Pr0methean
Copy link

On my machine (Ubuntu with GNOME Terminal, DroidSansM Nerd Font and Noto Color Emoji), the fog symbol 🌫 displays in the text font and is the wrong width, but the emoji align correctly with the other symbols when they only consist of ☀️ ⛅️ ☁️ (all of which display in the emoji font). Probably, the fix is for all emoji to be sent with VS16, since Unicode specifies that 🌫 defaults to text when no Variant Selector is specified and the symbol is in both fonts.

@mwolson
Copy link

mwolson commented Jan 25, 2025

Hi,

Here's what I'm seeing so far when I try the example command in #345 for several terminal emulators in Arch Linux:

Ghostty:

Image

Tabby (formerly Terminus):

Image

Konsole (Noto Emoji Font set at about 3-4 pts higher than the normal text font):

Image

File with those emojis in it: tmp.txt

Takeaways:

  • I'd be curious to see if the proposed configurable double-width change with symbols=0x1234 could address it in all cases. It's quite possible that the use of a separate emoji font size is messing with Konsole, especially; maybe there's a blank emoji-range character that could be used to force spaces to match the sizes of other emojis, but I'm not sure. Konsole could be the least easy to fix.
  • I do see that at least one iPad app rendered empty characters after some of the emoji, which makes me wonder if those were emoji presentation selectors.
  • It might be reasonable to introduce an extra query parameter just to control emoji presentation selector usage, perhaps something like presentation=none|emoji|text . none never adds a presentation selector, emoji and text always add their corresponding presentation selector. If we go with this, having the default value be emoji seems reasonable.

@mwolson
Copy link

mwolson commented Jan 25, 2025

Following up, when I set this ghostty option to legacy and reopen it, the text renders in perfect columns just like Tabby: https://ghostty.org/docs/config/reference#grapheme-width-method . Ideally the default behavior of wttr.in would be to have output that renders correctly when that ghostty option is set to unicode (the default) and let users provide an option to flip the output back to something compatible with legacy, perhaps that would solve a decent number of cases with minimal complexity.

@chubin
Copy link
Owner Author

chubin commented Jan 27, 2025

@Pr0methean @mwolson

I believe, the ideal fix would be to specify the way to calculate the width of the graphemes.
As the first approximation to the result, we could try to add the option grapheme-width-method option (or may be gwm for brevity), and see how many cases it will fix (and what cases will remain unfixed)

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

No branches or pull requests

3 participants