Problems rendering certain Unicode glyphs #501

Open
opened 2019-01-24 14:50:15 +01:00 by girst · 4 comments
girst commented 2019-01-24 14:50:15 +01:00 (Migrated from github.com)

Hi, I'm working on some terminal games that make extensive use of niche Unicode characters from e.g. the Box-drawing and Full-width forms blocks. Sadly, they don't render correctly in crt.

  • some box-drawing characters are wider than others ( vs )
    It looks like not all the glyphs from this block are in the supplied fonts (checked Terminus), so another will be used as fallback. All other terminal emulators I've encountered don't rely on the font specified glyph width, but align characters in a grid themselves.
  • "wart" on vertical bars
    all vertical bar glyphs have a protrusion on their right side. This affects all fonts, but in different intensity.
  • spaces introduced between full-width- and box-drawing characters
    full-width chars are supposed to have the same width as han (chinese/japanese/korean) chars, making them take twice as wide as 'normal' characters in a terminal. crt adds space (depending on the font negative space) between them and box drawing characters.

These might be problems in qTermWidget that just manifest in crt due to its special configuration. I've only managed to reproduce the third bug (but not 1 and 2) in qTerminal that also uses qTermWidget, so that's why I've decided to open this BR here first. Oh, and of course a big Thank You for making this awesome program!

Attached is the UTF-8 encoded testfile and screenshots I've made of crt and gnome-terminal
crt-alignment-demo
foo.txt

Hi, I'm working on some [terminal](https://gir.st/mines.htm) [games](https://gir.st/viiper.htm) that make extensive use of niche Unicode characters from e.g. the [*Box-drawing*](https://en.wikipedia.org/wiki/Box-drawing_character) and [*Full-width forms*]() blocks. Sadly, they don't render correctly in crt. * **some box-drawing characters are wider than others** (`╎` vs `│`) It looks like not all the glyphs from this block are in the supplied fonts (checked Terminus), so another will be used as fallback. All other terminal emulators I've encountered don't rely on the font specified glyph width, but align characters in a grid *themselves*. * **"wart" on vertical bars** all vertical bar glyphs have a protrusion on their right side. This affects all fonts, but in different intensity. * **spaces introduced between full-width- and box-drawing characters** full-width chars are supposed to have the same width as han (chinese/japanese/korean) chars, making them take twice as wide as 'normal' characters in a terminal. crt adds space (depending on the font negative space) between them and box drawing characters. These might be problems in qTermWidget that just manifest in crt due to its special configuration. I've only managed to reproduce the third bug (but not 1 and 2) in qTerminal that also uses qTermWidget, so that's why I've decided to open this BR here first. Oh, and of course a big Thank You for making this awesome program! Attached is the UTF-8 encoded testfile and screenshots I've made of crt and gnome-terminal [crt-alignment-demo](https://user-images.githubusercontent.com/11820748/51681514-b4e9d400-1fdc-11e9-9334-79bd570ce6cb.png) [foo.txt](https://github.com/Swordfish90/cool-retro-term/files/2791876/foo.txt)
Swordfish90 commented 2019-02-02 18:00:00 +01:00 (Migrated from github.com)

Hi @girst... I'm able to reproduce these issues, and I think they are inherited from upstream. As you correctly assumed, CRT uses very tiny font sizes when using non-HD fonts, making these issues even more noticeable.
It's indeed a bug, and not an easy one. For the moment I'd suggest you to use one of the HD fonts (or a system font).

Hi @girst... I'm able to reproduce these issues, and I think they are inherited from upstream. As you correctly assumed, CRT uses very tiny font sizes when using non-HD fonts, making these issues even more noticeable. It's indeed a bug, and not an easy one. For the moment I'd suggest you to use one of the HD fonts (or a system font).
7HEPOW commented 2019-04-26 10:04:07 +02:00 (Migrated from github.com)

Just to add a little more information just from looking at the font rendering:
It seems like it's using always the same characters to draw boxes. All vertical lines have those notches even when using system fonts that include proper box characters, some internal characters seem to be used or maybe even a fallback font. Here's an example using Pet Me 128 Medium:
Screenshots
Upper shot is on Tilix (also works in Terminator/xfce4-terminal/etc.) and lower shot is in CRT. I tried all fonts on my system all leading to the same result. Misalignment happens with some, but not all fonts.

Just to add a little more information just from looking at the font rendering: It seems like it's using always the same characters to draw boxes. All vertical lines have those notches even when using system fonts that include proper box characters, some internal characters seem to be used or maybe even a fallback font. Here's an example using Pet Me 128 Medium: [Screenshots](https://user-images.githubusercontent.com/35022098/56792202-5ca7b580-6809-11e9-8890-986d25e614e1.png) Upper shot is on Tilix (also works in Terminator/xfce4-terminal/etc.) and lower shot is in CRT. I tried all fonts on my system all leading to the same result. Misalignment happens with some, but not all fonts.
dessalines commented 2019-05-17 02:15:59 +02:00 (Migrated from github.com)

I'm noticing this problem even using system fonts, where it does show up correctly using that same font in other terminals.

I'm noticing this problem even using system fonts, where it does show up correctly using that same font in other terminals.
isaacclausen commented 2024-01-22 21:58:52 +01:00 (Migrated from github.com)

I'm having this issue still. All the vertical bar glyphs have a protrusion on their right side

I'm having this issue still. All the vertical bar glyphs have a protrusion on their right side
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: seeseemelk/cool-retro-term#501
No description provided.