The custom glyphs does not seem to render correctly. #4303
-
Details
An API returns logs that I need to display and for that I'm using Xterm.js to do that. Here is what the api returns: 2022-12-09T13:05:41.493882608Z �[34mâ•â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€â”€�[34m�[30m�[44m git repo clone �[0m�[0m�[34m───────────╼�[0m This is what I should have rendered: It seems that some custom glyphs are not rendering correctly. I have a codesandbox that can be used to test this. Could you tell me if my config is wrong or did I miss something, please? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Those What could cause the issue in the first place? Well, whoever writes the log file entries, prolly gets utf-8 bytes as input, but decodes them wrongly with an 8bit encoding, then re-encodes them as utf-8, example: >>> original_char = '─'
>>> incoming_bytes = original_char.encode('utf-8')
>>> incoming_bytes
b'\xe2\x94\x80
>>> corrupted_bytes = incoming_bytes.decode('cp1252').encode('utf-8')
>>> # now corrupted_bytes get saved to your file
>>> # then the following happens in the browser/xterm.js:
>>> print(corrupted_bytes.decode('utf-8'))
─ The ...
>>> good_bytes = incoming_bytes.decode('utf-8').encode('utf-8')
>>> # now good_bytes get saved to your file
>>> # then the following happens in the browser/xterm.js:
>>> print(good_bytes.decode('utf-8'))
─ (Used python to illustrate the issue, as JS lacks default encoders for the wrongly applied 8bit encoding here.) This has nothing to do with xterm.js, thus gonna close the issue. |
Beta Was this translation helpful? Give feedback.
-
Hi @jerch, thanks for the detailed answer, very helpful! |
Beta Was this translation helpful? Give feedback.
Those
─
are an double encoding issue at the task, that creates yourlogs.txt
, means that file is already wrongly encoded/corrupted. xterm.js understands JS strings (which are utf-16 under the hood) or byte sequences (utf-8 bytes) as input.What could cause the issue in the first place? Well, whoever writes the log file entries, prolly gets utf-8 bytes as input, but decodes them wrongly with an 8bit encoding, then re-encodes them as utf-8, example: