'Ⅲ' (U+2162) is an ambiguous width character according to the Unicode standard (version 8.0 or 9.0). If you go to Profile prefs -> Compatibility and choose Wide for them, it'll occupy two columns. You'll probably get tons of display problems though, since applications (e.g. bash's readline, ncurses apps etc.) will believe it's a narrow one and position the cursor accordingly. Unfortunately there are no locale definitions available where these are double wide, in all locale definitions these are defined as narrow characters.

It's a pity that the glyph itself doesn't fit in a single cell. What should VTE do then? I believe cropping would be even worse. It could also scale down, but that might also look ugly. Currently it overflows, maybe that's the best it can do. It's debatable, though.

I admit that it's inconsistent in drawing this overflow. E.g. when the block cursor is over this character, the cursor itself becomes wider (as wide as the glyph -- I have no clue if it's intentional, or where it is handled in the source code) and the entire glyph is painted correctly, hiding parts of the next one. This doesn't happen with the other cursor shapes (empty block on focus loss, I-beam, underline, or the "off" phase of a blinking block cursor), then both glyps are fully drawn, overlapping each other. I think it's rather by accident than intentional (when the inverted glyph under the block cursor is painted, it is totally ignored that it overflows another one).

That being said, I can't see what a proper, consistent, user-friendly solution would look like. Probably all other solutions would have downsides too, just as the current one.

Somewhat relevant: bug 734740.

Is this the same bug responsible for the following discrepancies between Terminator (left) and Konsole (right) using the ligation-enabled Iosevka font?

http://imgur.com/a/r9com

The first two screenshots: VTE does not support double-width and double-height lines in that old-fashioned terminal emulation sense where each letter is artificially magnified to twice its size.

The third screenshot: It's hard to tell what's going on without knowing what you print (at the very least, which Unicode symbol is the one looking like '='). VTE's layout seems to be okay for me. Konsole's issues belong to konsole's bugtracker.

Konsole is displaying those correctly, as far as I can tell. I used it to highlight what VTE was bugging out on. 

Those symbols aren't just looking like '=', they are '='. 

The exact strings are '0=0' and '= == = == ='. The VTE display is not ok, it looks crazy to me.

If there is a bug, it's not the same as comment 0. Ligatures are not supported (that's bug 584160).

Even though this issue is present when displaying a single '=' (no ligatures)? Also the Iosevka author makes a point of using ligations rather than ligatures.

Thank you, I'll eagerly be following 584160 in that case.

So, as far as I understand, the glyph for '=' is much wider than other glyphs, and it's a problem that VTE displays them in their entire width (overflowing) rather than cropping them? Terminals are supposed to work with monospace fonts, isn't this font hence a non-monospace one? I guess I'm missing something fundamental here, what's that? Something like the ascent-descent maybe, just horizontally?

Could you please point me to some docs explaining what's a "ligation" as opposed to a "ligature"? I couldn't find anything.

Also in bug 762832 I outlined why I believe the idea of using ligatures in terminal emulators is conceptually broken. Again I guess I'm not that popular with this opinion :)

Hi Egmont,

About your description in https://bugzilla.gnome.org/show_bug.cgi?id=762832, I suggest you try FiraCode font in iTerm if you have access to a macOS. It's an example of good (if not perfect) implementation of ligature in a terminal, another good example is Konsole, it supports ligatures very well. My text editor is vim and it has no problems with terminals supporting font ligature (actually text editors don't have to know about it at all, it all happens in terminal emulator). I used to work in iTerm and when I decided to migrate to Gnome from macOS I was able to do almost anything I did in mac in gnome. The only exception being the lake of ligature support in gnome-terminal. So I'm using Konsole in gnome which has its own problems. It'd be great if gnome-terminal/vte could support font ligature.

Regards,
Sassan

Hi Sassan,

> I suggest you try FiraCode font in iTerm if you have access to a macOS.

I don't.

> another good example is Konsole, it supports ligatures very well.

Konsole renders runs of cells of identical attributes in a single step, so the font engine can render ligatures (as long as the characters are of the same attributes; not across e.g. a color change). And if some of the glyphs don't have the exact desired width, the whole layout falls apart easily, glyphs can get pushed far-far away from their desired position (and crazily jump back and forth as you move the cursor, or highlight with the mouse). In terminal emulators I believe it's more important for glyphs to keep their desired position, than to have nice ligatures. Truly beautiful rendering is mutually exclusive to a strict grid of fixed width characters, and terminal emulators are primarly about the latter. For truly beautiful rendering there's the graphical system.

> It'd be great if gnome-terminal/vte could support font ligature.

I guess we all agree on this, there is definitely room for VTE to improve. But there are tradeoffs that have to be evaluated, priorities that need to get done right, plus this whole thing needs to be implemented by someone.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2395.