Some monospace characters are not rendering as proper monospace

[bitwiser73]

Summary

Basically, for monospace font, the asian characters width should be equal to two of ascii's. When using the same font (Ubuntu Mono Regular), it works on gnome-terminal but not in ST3. This rendering issue affects some softwares and might not be directly related to ST3 (see http://denisbider.blogspot.fr/2015/09/when-monospace-fonts-arent-unicode.html ).

Expected behavior

Here's the rendering with gnome-terminal

Actual behavior

I also found in ST3 forum an issue with mathematical symbols that might be related

The issue for my ST3 plugin : https://github.com/bitwiser73/MarkdownTableFormatter/issues/4

Steps to reproduce

This is the copy/paste from my terminal, it might not render correctly in your web browser. Paste it in ST3.

|Ｔａｂｌｅｓ　　　|　　　　Ａｒｅ　　　　　|Ｃｏｏｌ　　　　　　　　　|
|:-----------------|:----------------------:|:-------------------------|
|ｃｏｌ　１　ｉｓ　|ｌｅｆｔ－ａｌｉｇｎｅｄ|＄１６００　　　　　　　　|
|ｃｏｌ　２　ｉｓ　|　　ｃｅｎｔｅｒｅｄ　　|＄１２　　　　　　　　　　|
|ｚｅｂｒａ　ｓｔｒ|　　　　　　　　　　　　|ａｒｅ　ｎｅａｔ　　　＄１|
|　　　　　　　　　|　　　　　　　　　　　　|＄ｈｅｌｌｏ　　　　　　　|
|＄２　　　　　　　|　　　　　　　　　　　　|　　　　　　　　　　　　　|
|业务方向　　　　　|　　　　　线人　　　　　|线人２　　　　　　　　　　|
|运营后台　－　销售|　　　雪、鹏、丽　　　　|雪、　　　　　　　　　　　|
|智能商业部　　　　|　　　　　瑞　　　　　　|雪、　　　　　　　　　　　|

Environment

• Ubuntu 16.10 with default fonts (Ubuntu Mono Regular)
• ST3 build 3126

[wbond]

My guess is that the font metrics being returned by pango/fontconfig are not reflecting what the width should be. We don't calculate character widths ourselves at all.

In fact, we measure character widths to determine if a font is monospace or not, however that measurement utilized just ASCII characters (m and i if I recall correctly). If a font is not monospace, we disable bold and italic since it can lead to text shifting while typing.

It seems to "fix" this, we would have to detect a font as monospace, and then try to utilize http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt to adapt our glyphs. That said, I'm not sure what other affects it may have trying to deal with some glyphs being double width.

My guess is that this won't be addressed in the near term, just due to the complexity. Instead, it would seem to me to be the kind of thing that may be investigated when looking into some other advanced font-related issues.

[bitwiser73]

I've never used pango, there must be a reason why sublime doesn't use those. Anyway, I've noticed that there are two handy functions: pango_font_family_is_monospace() and g_unichar_iswide() which might help to solve this issue. Thank you

[FuriousProgrammer]

This issue affects more than just asian double-width characters; many "esoteric" unicode characters aren't using the correct widths.

Comparing with Notepad, using Consolas font in both:

ST4 appears to be rendering ⨯ and ∪ very slightly too wide, and ∅ very slightly too narrow (IMO, as ∅ is a square character, and could also be represented as a ligatured {}). All the subscript and box-drawing characters are the correct width, as is ∩.

Notepad shrinks ∅ to almost a single character's width: it's very slightly too wide, but that isn't shown in the screenshot, and otherwise renders every character as correctly monospace.

[rsalmei]

I'm on macOS Sublime Text 4 and I've just stumbled on this, at least it seems related. In iTerm2 an ASCII table is perfectly aligned but it messes up when pasting into sublime, even if using the exact same font and size.

[rchl]

Maybe it's this "Use built-in Powerline glyphs" option that makes it work in iTerm2.

[rsalmei]

Thanks @rchl, but unfortunately it isn't. I tried disabling it, as well as Unicode version 9+ widths and normalization form, and it keeps perfectly aligned.

[rchl]

It could be that those characters don't exist in the font you've selected and iTerm2 fallbacks to ascii font while ST to some default sans-serif font.

[rsalmei]

Humm that's interesting! Is the default ST ASCII font configurable? Actually, I don't think this font would miss characters since it is a nerd font.