Font-awesome: Font Awesome 5+ Does not render correctly using Windows GDI/Cleartype

[needforsuv]

Font Awesome 5+ Does not to render correctly when Windows GDI is being used to render the font
This effects
Windows 7 Desktop Fonts
Charmap (for copying and pasteing fonts)
Other Font programs which use GDI for rendering (A lot of them)
Chrome <51 (GDI MODE)
Yandex 14 (Based on Chrome 38) (GDI Mode)
WHICH IS Stated as being supported by
https://fontawesome.com/how-to-use/web-fonts-with-css#browser-support
Other Apps which use GDI/Windows Cleartype rendering including: Word 2010?, Excel etc when calling for or drawing FA5

13131

12693

The problem is the GDI seems to ignore or refuse to draw most of the icons in FA5 and return as a BOX or blank.
At first this SEEMED to be browser or extension/website problem UNTIL I had the BRILLIANT idea to check GDI. THE BROWSER HAS nothing to do with rendering problems... ITS FA5 and GDI/Cleartype
The ONLY reason WHY this appears to be a browser / OS problem is that NO major browser today uses windows font rendering anymore, its in-house or some other rendering technique that's not GDI. And the switch happened right around the time XP and Vista stopped being supported.
I see this as a MAJOR problem because you just broke the FONT on Windows Desktop for most people who don't even know why it is broken.
Note: FA4 works PERFECTLY with GDI
I know font weights and stuff can be hard to make backwards compatible but when you make the font not work on the desktop it really limits the developers and users. MAINLY it is impossible to just copy and paste from charmap etc when the fonts won't even render and you have to rely on svgs and manual input of the unicode/font number? and hopeing it works right.

[needforsuv]

Update with Pictures (using brands because less icons to deal with)
As far as I can tell WEBFONTS are hinted differently than the desktop ones
FA5 WEBFONT on Windows 7 (Few Icons rendered by windows)

FA5 Desktop (More icons rendered but I am UNSURE of the total due to there being codepages for ALL or MOST characters avaliable in unicode and A lot of unneeded ones (foreign language) and spaces

FA4 Webfont: WORKS just fine using windows cleartype / gdi

(all icons are present)
PS: I am using the webfonts for FA4 because its easier than the desktop one with all the unneeded codepages

I suggest testing this by having a local self contained webfont/desktop font file with .css and html
and opening it in various programs and browsers to see which parts do or DO NOT render.
(Maybe with webfonts in one section and desktop fonts in another)
Maybe use the brands file since that has a more limited code set

[tagliala]

Hi,

I'm trying to replicate this issue with charmap

• Windows 7 SP1 v6.1.7601 running inside VirtualBox
• Font Awesome 5.0.13 .otf file (use for desktop)
• Charmap

With ClearType disabled:

With ClearType enabled:

---

but I was able to reproduce with Yandex 14.7, without DirectWrite, because it crashes

SVG works instead

@robmadole could you please take a look?

PS: is there any reason for supporting yandex 14 (based on chrome 35)?

[needforsuv]

I knocked together a quick dreamweaver file (it doesn't use the provided css because I am not sure how to do it)
Desktop Font Renders fine: (Crashes chrome though as I suspect .otf (desktop) is not meant to be rendered in a web browser)

Webfonts however: DON'T render in dream weaver _(the problem seems to with webfonts)_

FA4 Webfont (installed on system):

(still crashes chrome but thats probably me doing html wrong)
PS: I don't know what rendering engine dreamweaver cs6 uses... but it appears to suffer from the same problem albeit with grayscale GDI/Cleartype
I am saying this may not be browser specific rather webfont specific.
Somewhere from FA4 to FA5 webfonts something broke FA's ability to render in windows (WEBFONT version) and since the desktop font is slightly different (in that it works fine?) using that and switching to the webfont at publishing may not raise any issues. BUT if you were to develop using webfonts in an application that relys on windows font rendering there may be an issue.

EDIT:
WEBFONT in CS5 (with subpixel cleartype) (standard css)

PPS: Yandex 16.7.1.20936 is the last version with internal chromium 51 and each 1X.X version of yandex spans serveral chromium versions...
SO 2 major revisions of yandex is like (version 16 is 47 to 54 so 7 versions) *2 = 14 Chromium versions
PPPS: Chrome 37 Introduced Directwrite and Chrome 52 dropped GDI; Firefox and IE (IE9 in IE 8 Mode) both emulate GDI when asked to (I think) because they don't have problems
LET ME MAKE IT CLEAR this is NOT a browser issue, its a font rendering issue with the WEBFONTS version of FA5 that occurs on at least (This is probably long enough I'll wait to add stuff to it)

OKAY SORRY FOR THE edit spam but I FOUND SOMETHING

FA4 WEBFONTS were complied by FONTLAB
FONTLAB:OTFEXPORT (babelmap font info)
but the FA5 WEBFONTS were made by Fontello
Generated by svg2ttf from Fontello project. (babelmap font info)
AND IF YOU go to the Fontello site the EXACT SAME PROBLEMS OCCUR EVEN WITH FA4 SVG's (with GDI rendering)
So here is what I did I IMPORTED the desktop fonts(.otf) to fontlab AND EXPORTED as .ttf (with some errors blah blah) (i deleted afterwards). IT WORKS JUST FINE!!!
PS: Fonts works fine If I download fonts using FF or Chrome 51
BUT it only renders in FF... or Chrome without GDI

[tagliala]

Desktop Font Renders fine: (Crashes chrome though as I suspect .otf (desktop) is not meant to be rendered in a web browser)

Right. And .ttf files are not meant to work on desktop

Anyway, thanks for all the information and let's wait for @robmadole's feedback on this

[needforsuv]

But lots of windows fonts are .ttf
and fontello fonts work fine in .tff
Lets list common TTF fonts
Arial, Comic Sans, Impact, Segoe UI, Times New Roman are all TTF
And lets list OTF Fonts
AdobeXXX, HelveticaNeueXXX, MyriadXXX, OCRX
i know the webfont ttf may be different but it should still render
So it probably goes both ways

[robmadole]

Ok. Thanks @needforsuv for reporting this. We'll get this on the list.

[currchar]

We are using the Fontawesome TTF fonts in a Windows desktop application. As long as we used Fontawesome 4 it all worked fine.
After the upgrade to Version 5.0.13 only the icons 0xf020 to 0xf0ff were accessible. So we used the workaround that @needforsuv mentioned and exported ttfs from otf. In these fonts all symbols were accessible, but looks blurred. When using the otfs the symbols are even more blurred, especially in light style.
Could you please complie further updates of Fontawesome with the old parameters of Fontawesome 4 to make sure, everythings works as fine as with Fontawesome 4 again?

[tagliala]

@currchar please open a new issue providing as much details as you can, including operating system, font size, screenshots etc.

Please also keep in mind that the base font size changed from 14px to 16px, so you should use 16px and multiples to have pixel perfect icons