fa-solid-900.ttf misreports font-weight as 400, not 900

[tcrgit]

I was unable to use the .far & .fas css classes to switch fonts with both the fa-solid-900.ttf and fa-regular-400.ttf fonts installed. I opened the fonts with the BirdFont editor to inspect them, and both listed the same font-weight of 400. I modified the fa-solid-900 font weight to 900, replaced the font files and the css works perfectly.

This could be human error, or a bug in whatever script is used to generate the fonts.

I double checked the .otf files as well, and the same problem was present there also. This applies to 5.0.13 font awesome 5 free.

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

I was unable to use the .far & .fas css classes to switch fonts with both the fa-solid-900.ttf and fa-regular-400.ttf fonts installed.

Could you please provide more details?

Where does that happen? On a webiste? I can't reproduce: https://jsfiddle.net/tagliala/6yrybgho/12/

If you refer to css and classes, why did you install the ttf font files on the system?

I opened the fonts with the BirdFont editor to inspect them

Please use .otf files for desktop usage

I double checked the .otf files as well, and the same problem was present there also.

Could you plesae provide a reproducible test case of the issue?

Please make sure that your request follows our bug report template

[tcrgit]

Sorry, my report regarding what environment I encountered this in should have been clearer. I was using the FontAwesome fonts on iOS, installed via a NativeScript app. Hence I was not using the otf fonts (for space-saving reasons) and was not installing the otf desktop fonts onto the host macOS system.

Due to that lack of context, your jsfiddle probably won't help reproduce it. To reproduce the issue, it would be much simpler to simply open the fonts in a font editor (eg BirdFont, FontForge, whatever), and verify whether the reported weights for fa-solid-900 and fa-regular-400 are in fact both 400.

I can report that on MacOS, in the BirdFont editor, the font-weight for fa-solid-900 was incorrectly reporting as 400, and not as 900. I tested both the ttf fonts and the otf fonts and saw the same problem in both places.

The bug backstory is that when the font-weights are set incorrectly to the same value on multiple fonts in the same font-family, on iOS (& specifically at least when running a NativeScript app) there is a conflict. iOS will always choose one due to what appears to me to be the erroneous font weights in the FontAwesome distribution. When applying following css to two different text strings, both appear in the solid font as the font-weight differentiation below has no effect due to the internal font-weights both being set to 400.

.fas {
  font-family: 'Font Awesome 5 Free';
  font-weight: 900; }

.far {
  font-family: 'Font Awesome 5 Free';
  font-weight: 400; }

Using a font-editor to correctly set the font-weight of fa-solid-900 to 900 resolves this problem, and the css works.

This is why I suggest you reproduce the issue in a font editor rather than spin up an entire iOS NativeScript mobile app development context. Desktop browsers and OS installations may handle this error differently, and there are conflicting bug reports about whether installing the FontAwesome otf fonts can help work around the iOS/NativeScript presentation issue. For further backstory, see NathanWalker/nativescript-ngx-fonticon#37

There are similar reports regarding Font Awesome Pro, specifically regarding Solid being substituted for Light as well. If I am right, and you can reproduce the misreported font weights, I strongly suggest you examine your font-generation scripts (svg2font?) and/or your release process to address this font-weight issue.

[tagliala]

@tcrgit thanks for the detailed explanation

@robmadole could you please take a look here?

[robmadole]

I can confirm this. I'll get it on our list to look at. Thanks @tcrgit for the bug report.

[mediadeo]

any updates on this, or a link to the font with the correct fontweight setting applied ?

[robmadole]

Alright, we should have this fixed in 5.7.0. It's showing up correctly in our build system.