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

problem with brower version interpretation of multiview ncruses+UTF+ emoji #185

Open
Popolon opened this issue Jan 15, 2022 · 9 comments
Open

Comments

@Popolon
Copy link

Popolon commented Jan 15, 2022

This record works perfectly in terminal, but not in browser (emoji made moving characters are not drawn at their place):
https://asciinema.org/a/461817

This is based on an interactive C program using ncrses with several view + UTF (multibytes) characters including chinese (uniHan) + emoji characters.

Source code is available here:
https://framagit.org/popolon/emohanjeu

@normen
Copy link

normen commented Jan 15, 2022

Emoji/UTFmultibyte in the terminal is a huge can of worms, this issue has been with asciinema for a long time now.

@Popolon
Copy link
Author

Popolon commented Jan 21, 2022

asciinema plays them perfectly in term at least. On this asciideo (if I can say), I looks like only emoji are not at a good place, and shift in some cases other 2bytes UTF8 chars.

@normen
Copy link

normen commented Jan 23, 2022

In your term. Try another one :)

@Popolon
Copy link
Author

Popolon commented Feb 19, 2022

Tried with several terminals, xfce4-term, terminator, lxterminal, xterm & uxterm (these two don't manage emoji font , and display squares inside, but still well formated), weston-terminal in weston displayed in an X11 windows (only squares, but well formated too), all worked fine at playing asccinema of this emoji+hanzi chars record. I made it caruflly with ncurses to have good term output.

Also tried on remote host with different architecture (ARM, RISC-V (both real hw and qemu)) via ssh, works fine too.

@ku1ik ku1ik transferred this issue from asciinema/asciinema May 17, 2022
@ku1ik
Copy link
Contributor

ku1ik commented May 17, 2022

Indeed asciinema-player doesn't support double-width characters (which includes many emojis) at the moment. It's a known limitation. Hopefully we'll address it at some point although it's not a high priority issue.

@yaojiqunaer
Copy link

How I wish it could be restored

@ku1ik
Copy link
Contributor

ku1ik commented Mar 26, 2024

The recently released 3.7.1 version of the player got several improvements around rendering accuracy, mostly fixing positioning and alignment of various character groups (ascii drawing, block elements, Powerline symbols, CJK, emoji). It should look much better than before now.

The recording linked by @Popolon looks like this for me:

image

Is this more or less how it should look?

@Popolon
Copy link
Author

Popolon commented Mar 26, 2024

There are still the same problem as soon the characters move sadly. You will see for exemple the character 森 (forest) in green that appear at some random position when the wolf head emoji character move inside the forest, or the right bar with a test reference with existing bg used characters that move after few second, but they are fix in a term, asciinema work fine in term.

You can compare the terminal and web version to see the differences.
image

@ku1ik
Copy link
Contributor

ku1ik commented Mar 27, 2024

Got it, thanks for the clarification 👍

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

No branches or pull requests

4 participants