vscode: "l·l" Ligature in "Source Code Pro" incorrectly invoked when render whitespace is enabled

VSCode Version: 1.49.0
OS Version: Windows 10

Steps to Reproduce:

Set editor.renderWhitespace to all.
Set editor.fontFamily to Source Code Pro (ensure you have the font installed on your system).
Set editor.fontLigatures to false (this issue is not reproducible if this setting is not set to false).
Open a new editor and type l l (a lowercase letter “l”, followed by a space, followed by another lowercase letter “l”).

Screenshot of this bug:

When editor.renderWhitespace is set to all, the whitespace character (U+0020) is rendered as the middle dot unicode character, · (U+00B7). Coincidentally, “Source Code Pro” has a ligature that comprise of the characters l·l (see the screenshot above), so this might be the reason why the ligature is invoked.

Does this issue occur when all extensions are disabled?: Yes

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 46
Comments: 17 (6 by maintainers)

Commits related to this issue

[Bugfix] vscode: Source code pro ligature see: microsoft/vscode#106583 Signed-off-by: Piyush Pangtey <gokuvsvegita@gmail.com> — committed to pangteypiyush/dotfiles by pangteypiyush 3 years ago
[Bugfix] vscode: Source code pro ligature see: microsoft/vscode#106583 — committed to pangteypiyush/dotfiles by pangteypiyush 3 years ago
Fix incorrect ligatures when rendering whitespaces Fixes microsoft/vscode/#106583 — committed to Long0x0/vscode by Long0x0 2 years ago
Fix incorrect ligatures when rendering whitespaces (#150349) Fixes microsoft/vscode/#106583 — committed to microsoft/vscode by Long0x0 2 years ago

Most upvoted comments

Workaround: ~~configure "editor.fontLigatures": "'liga' off, 'calt' off"~~ configure "editor.fontLigatures": "'ccmp' off"

+42

alexdima on Sep 17, 2020

The fact that the editor uses an actual text character (·) to implement whitespace indicators seems like an implementation detail. I’d say since the user didn’t intentionally insert ·, its a bug if ligatures fire on that character sequence. Maybe not easy to fix (I don’t know), but I do think this is a bug. The user entered l l (elle space elle) not l·l (elle dot elle) and the ligature is not intended to trigger for l l.

Furthermore, the caret positioning for the rest of the line becomes incorrect: See this result with the problematic ligature turned on: See this result once "editor.fontLigatures": "'ccmp' off" is applied:

Furthermore, the caret position jumps around when faced with navigating the line after the ligature occurs, and selection also assumes it is rendered as if the ccmp feature is off:

+12

rezonant on Sep 23, 2020

Copying here what I commented in adobe-fonts/source-code-pro#260:

IMHO that should be solved by VSCode by switching to the proper Unicode character, U+2027, instead of reusing U+00B7, which is an orthographic character in the Catalan language and other related Romance languages like Occitan. VSCode shouldn’t ask font developers to make their fonts substandard in a human language to accomodate for their software’s quirks.

fitojb on Jan 20, 2021

OK. I have actually found out quite a number of things while investigating this:

https://wakamaifondue.com/ can be used to upload a font and get a list of all the font features settings available in that font
Source Code Pro has 37 available font feature settings: 'case', 'ccmp', 'cv01', 'cv02', 'cv04', 'cv06', 'cv07', 'cv08', 'cv09', 'cv10', 'cv11', 'cv12', 'cv14', 'cv15', 'cv16', 'cv17', 'dnom', 'frac', 'locl', 'numr', 'onum', 'ordn', 'salt', 'sinf', 'ss01', 'ss02', 'ss03', 'ss04', 'ss05', 'ss06', 'ss07', 'subs', 'sups', 'zero', 'mark', 'mkmk', 'size'
By doing a binary search on them, it is the font feature setting named 'ccmp' that is causing l·l to be rendered with a different glyph.
Here is what I could find about ccmp
It looks like Source Code Pro registers a ligature for the character sequence l·l. The · is the character we use to render whitespace.
This ligature is no longer disabled via 'liga' off, 'calt' off as it used to be the case in the past.

TL;DR: This has changed since VS Code 1.49 because we have upgraded to Electron 9, which ships layoutNG. I am not convinced this is a bug, it might just be something unique about Source Code Pro. The workaround is to use "editor.fontLigatures": "'ccmp' off"

alexdima on Sep 17, 2020

This is still a problem, and having to set ligatures to "'ccmp' off" is not a great fix. I assumed that setting ligatures to false would turn ligatures off, not … ignore settings related to them? I guess? (I’m not actually sure what it does). More intuitive or expressive options for editor.fontLigatures would be a good thing, as would not having ligatures show up due to rendered whitespace.

farfromunique on Nov 9, 2021

Just updated to latest VSCode. This issue remains unfixed.

av-2024 on Apr 5, 2022

I’m a bit confused. The text being rendered is already different from the text being interacted with (e.g. there’s a dot there, where there isn’t in the text). So why can’t we just render &NoBreak;<dot>&NoBreak; (or similar with ZWSP, etc. – any of the zero-width space characters) to break up the ligature? I don’t actually know Unicode well enough to say which would be the best, NoBreak was just the first one I thought of.

That way we preserve the aesthetic, which admittedly I do like the best out of the options, while still not causing problems for fonts which define the Catalan ligature, AFAIK without needing to tweak rendering code significantly.

ETA: my hesitation isn’t sarcasm, I’m just not familiar enough with VS Code’s internals to know whether this is really an option.

nic-hartley on Apr 19, 2021

I had the same issue. @alexdima 's fix solved the issue.

"editor.fontLigatures": "'ccmp' off"

jonnyhoff on Jan 20, 2021

@jonnyhoff me too

icelewsi on Dec 23, 2021

Just a reminder that this bug is still a problem (deb package version 1.56.2-1620838498).

imaami on May 23, 2021