GitGutter Popup - Missing Symbols/Icons

[skjbulcher]

I'm having issues with some of the icons/symbols in the GitGutter popup.

Sublime Text 3, Build 3124
Fresh install of GitGutter

[r-stein]

All the icon are actually unicode characters. Therefore I would assume, that these characters are missing in your font. Do you use the default font or a special font?

[skjbulcher]

I'm using the Source Code Pro font. I had a hunch about the font as well, but deleting the font from my user preferences (and saving it) did not make the problem go away. Does it require a restart of ST3 for new fonts to take effect in GitGutter? Does the Windows default font contain those characters / what is a good font to use? I rather like Source Code Pro.

[skjbulcher]

OK, I confirmed your suspicions with a little more digging: After changing the font to Times New Roman (yes, I went there), the symbols appeared correctly.

The default font in Windows does not have definitions for the characters in questions; neither does the illustrius Source Code Pro font. Neither do I recommend Times New Roman as a programming font ;) Since changing fonts is an unwelcome workaround for users who values their favorite font (and by default GitGutter is broken in a fresh Windows 10 install), I feel this aught to be addressed.

Since the nature of this issue has changed, should it be listed as a duplicate of another issue (e.g. #308)?

[r-stein]

I also use Windows and have the symbols on both Source Code Pro and the default font. Obviously changing the font just fix the popup is not a solution.
Not sure how we should solve this. We could switch to image icons, but that will require tinting the image to fit the color scheme and might create new issues on high dpi displays.

Althrough the issues sound familar they and their solution are different and should not be merged.

[skjbulcher]

Something weird just happened. I tried a number of different fonts, but none of them worked. Then I reverted back to Times New Roman, but this time it didn't work for me. I restarted Sublime Text, and that did nothing.

Maybe comparing our fonts and user options might be useful?

font-related config options:

    "font_face": "Source Code Pro",
    "font_options":
    [
        "gray_antialias",
        "subpixel_antialias"
    ],
    "font_size": 9,

Source Code Pro font information:

Version: Version 1.0.17;PS Version 1.000;hotconv 1.0.70;makeotf.lib2.5.5900
OpenType Layout, Digitally Signed, TrueType Outlines

[r-stein]

It works for me with the same settings and in the font information I only have a small difference (I am using Windows 7)

Version: Version 1.0.17;PS Version 1.000;hotconv 1.0.70;makeotf.lib2.5.5900
OpenType Layout, Digitally Signed, PostScript Outlines

[skjbulcher]

I was using the TTF fonts. I just switched to OTF after uninstalling the old fonts and even rebooting, That gives me the "PostScript Outlines" you see on your system, but there is no change in the Sublime Text symbols.

In truth, I have a later version of the OTF font than you have now, but I'm not sure which version to download to test the same configuration as you:

Version: Version 2.030;PS 1.0;hotconv 16.6.51;makeotf.lib2.5.65220
OpenType Layout,Digitally Signed, PostScript Outlines

[skjbulcher]

Interestingly enough, when I did a search for the revert changes to the state in git arrow from the README, I discovered it was called an anticlockwise gapped circle arrow. I looked it up in the Caracter Map Windows app on my PC, and discovered it was U+27F2, and did not have a shape associated with it.

Either my font is defective, or yours has a few extra characters. Where did you get your font? Did you build it yourself?

[r-stein]

I don't remember from where, but I just installed it. However since it is not just in Source Code Pro, but in every font, I doubt it is about the specific font installation.

[skjbulcher]

Can you verify that the character exists in your "Source Code Pro" font through your Character Map program for me (advanced view, Go to Unicode "27F2")? I can't find the symbol in that program at all for a number of different fonts. I also checked to see what font the browser used to render the readme page, and it was using "Cambria Math", even when I specified a different font. Incidentally, "Cambria Math" does have the symbol for U+27F2.

I am at a loss. I don't know what else I can do to troubleshoot this on my system without spending a lot more time figuring out how the Sublime Text plugin system works, and I don't have time to do that. You're saying that it "works for me", so now I don't see this issue getting resolved. Any thoughts?

[skjbulcher]

I did just have one idea though - maybe your edition of Sublime Text 3 is rendering the font the same way as the browser does for me (using the "Cambria Math" font), whereas my editor is confining itself to the selected font. That could explain the behavior.

[skjbulcher]

OK, I just discovered something interesting. Copying and pasting the ⟲ character into ST3 yielded a generic no glyph symbol as shown in the original post. However, upon enabling the directwrite under font_options, it rendered correctly in the editor (although the extension continues to render the missing glyph icon). I read somewhere it might do this through some type of substitution mechanism. What theme are you using? I'm starting to think that something on your system is enabling directwrite in your extension not for me.

[r-stein]

I can confirm, that it does not exists in source code pro on U+27F2 either. I may switch to image icons instead of characters to resolve this issue, but even if I am going on this path it may take some time and I am afraid, that it will yield more issues.
I also have the symbol with the default color scheme (monokai) and the default theme. Since directwrite is a Window API it might also be something with Windows 10 vs Windows 7.

[JimAmuro]

Same problem here...
Windows 10 user. Changed several fonts. No luck at all...

[wbond]

I believe I know what is going on.

Sublime Text uses different backends for fonts on Windows depending on whether or not you are using a HiDPI screen. On non-HiDPI, we use GDI, whereas for HiDPI we use Skia. GDI has a mechanism for finding a glyphs that a missing from the selected font from another font and filling them in. Unfortunately Skia does not have that functionality, but handles HiDPI much better than GDI.

For the actual editor, we have a layer that sits on top of the font engine that allows us to do the glyph substitution, however that implementation is tailored to the editor control, and can't be easily used for minihtml.

This issue also affects editor tabs, as can be seen on sublimehq/sublime_text#1066.

The solution isn't trivial, and requires integration of a library such as harfbuzz, or using our own implementation such as we use on the editor component. It is definitely something that will be addressed, but I don't have an ETA.

[rchl]

I will just add, as it wasn't clear to me from your message, that it happens for me both on Win7 and Win10 on non-HiDPI screens.

[FichteFoll]

Here's another sample: It works on my HiDPI (1.25) Windows 10 machine but does not on my non-HiDPI Windows 7. Using Consolas on both.

[JimAmuro]

OK, it did work under HiDPI, i.e., if I don't set dpi_scale=1.0. Also some missing symbols in files show up. However, some CJK and other symbols in tabs and status bar become missing. I think maybe the render engine is different for the two parts? Such a dilemma...

[r-stein]

• we could read the button text from the settings, so anyone could just search for a available character or text
• we could just use images, load and tint them with the appropriate color (I think css tinting of images is not yet available, but scaling is)

[FichteFoll]

Images would be awesome. That way the glyphs would also always be of the same size, which the "approximately equals" and "not approximately equals" glyphs are not for me.

[skjbulcher]

What about using svg icons? I'm not very familiar with them or Sublime
Text's way of handling images, but I know it is possible to alter their
color on the fly.

[wbond]

No, minihtml doesn't support SVG at this time. I'm not sure if we'll go down that path in the future or not, since SVG can be rather involved.

I would think an icon font would probably be the most reliable, right?

[r-stein]

@FichteFoll I am not so happy with "approximately equals" and the "copy" either. If anyone has a better idea for "show/highlight differences" and "disable highlight diffences / highlight code", I will be glad to change it

@wbond Using icon fonts sounds like a good idea. This would have to be added to ST? (Aside from this it would also be useful to support tooltips.)

[wbond]

Yes, I would need to look into adding webfont support to minihtml. I had done some investigation into this before, but there wasn't a lot of info about using app-specific fonts on some platforms.

[barkan]

I found a simple workaround on my Windows 10 machine.

There's a "hidden" DPI scale setting for windows which is almost entirely useless in Sublime on Windows (works great on Mac, though). On Windows, it spaces things out and looks terrible.

However, through some trial and error, I discovered you can use the DPI scale to fix the icons, even with the tiniest DPI Scale.

{
	"dpi_scale": 1.0001,
        // more settings
}

.

[wbond]

@barkan I believe changing the dpi_scale is triggering using directwrite for font rendering instead of gdi. You could just set "font_options": ["directwrite"], in your settings and see if that accomplishes the same thing.

Using dpi_scale for anything other than working around Linux distros that don't properly report HiDPI is probably not a good idea.

[JimAmuro]

@wbond Actually not, at least for me changing to "directwrite" doesn't work.

[wbond]

@JimAmuro I'll have to look into the font selection – it may be that the font options aren't being used when picking fonts in minihtml. Either way, dpi_scale of any value other than 1.0 triggers alternate code paths for a number of things, assuming that we are dealing with a HiDPI display. While we default to GDI because so many people on Windows are familiar with the exact font rendering GDI produces, generally directwrite produces higher fidelity results.

[barkan]

@wbond directwrite doesn't get it done for me, either. Just fyi.

[deathaxe]

directwrite is my default since using ST without making fonts work in popups. Already tried to turn it on/off. Pasting the button icons to a normal view gets them rendered correctly. Tried with Segoe UI, Consolas, Source Code Pro font. Changing dpi_scale works for me, too, on Win10 but the copy button still shows wrong icon.

[deathaxe]

This bug is caused by GDI rendering shortcomings and is fixed with ST3 3127+ with DirectWrite being used for font rendering.

For those who still keep using GDI: This issue can't be fixed for you!

For further details see: sublimehq/sublime_text#1675 (comment)