UIFontWeightTrait not set on iOS

[hampustagerud]

Describe the problem

I am maintaining the FontAwesome 5 part of oblador/react-native-vector-icons in which we currently use hacks to get the right style to be chosen by React Native.

In the core of React Native it uses the UIFontWeightTrait trait to compare fonts of the same family. However, all Font Awesome 5 fonts are reporting a font weight of 0 which makes it impossible to predict (or choose) which style will be used to render the icon.

We are using the *.ttf files but .otf has the same problem.

What did you expect?

I would like the UIFontWeightTrait to differ between the different styles in order for Xcode and React Native to be able to select the fonts natively.

What version and implementation are you using?

Version: 5.3.1 (Pro and Free)

• SVG with JS
• Web Fonts with CSS
• SVG Sprites
• On the Desktop

Reproducible test case

I use the following code to check traits:

for (NSString *family in [UIFont familyNames]) {
  if ([family hasPrefix:@"Font Awesome 5"]) {     
    for (NSString *fontName in [UIFont fontNamesForFamilyName:family]) {
      UIFont *font = [UIFont fontWithName:fontName size:12];
        
      NSLog(@"%@", fontName);
      NSDictionary *traits = [font.fontDescriptor objectForKey:UIFontDescriptorTraitsAttribute];
      for (NSString *key in traits.allKeys)
        NSLog(@"\t%@: %@", key, [traits valueForKey:key]);
    } 
  }
}

Which produces:

Brands are never an issue since they have a different family name.

Bug report checklist

• I have filled out as much of the above information as I can
• I have included a test case because my odds go way up that the team can fix this when I do
• I have searched for existing issues and to the best of my knowledge this is not a duplicate

Possibly related to: #13557

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

We are using the *.ttf files but .otf has the same problem.

Please do not use the .ttf files since they are optimized for the web and for ancient browsers

I will leave this open, but I suppose this depends on #13557

[hampustagerud]

Thank you for a fast reply 🙂

Please do not use the .ttf files since they are optimized for the web and for ancient browsers

There are a couple of reasons why .ttf files are used instead of .otf. The package also targets react-native-web which could mean that the files might end up being used on the web. We are also using a script to auto-update the fonts using your npm packages and since they don't include .otf files it's easier to just use .ttf instead. Smaller filesizes are just a bonus as well 🙂

Now, if the fix would be to use the .otf I wouldn't mind changing the code but for now its not. If this was the case it would be greatly appreciated if there could be a @fortawesome/fontawesome-desktop package (or maybe include the .otf files in the standard packages) so downloads could be easily automated (I have also written a utility to upgrade the fonts to Pro, if the user has a npm-token, which is quite useful when there has been a new release).

I will leave this open, but I suppose this depends on #13557

I suspect this might be resolved by #13557 but not sure since the issue is a little bit different (maybe has the same fix though). I appreciate that this is left open until #13557 is resolved in case it is a different issue.

I will try to look into it more myself but I have very limited experience when dealing with the internals and meta-info of font files which I think is the cause of this issue 🙂

[tagliala]

which could mean that the files might end up being used on the web

Can you do the same with .woff2 or .woff?

[hampustagerud]

This is currently no option and really shouldn't make a difference. Other fonts are working fine using .ttf, .otf could be an option but .ttf would be preferable.

Also, maybe related to #13320 as well.

[robmadole]

@hampustagerud does this help? These are the numbers from what will be 5.7.0.

[hampustagerud]

@robmadole Yes, that looks correct 🙌 I think they are the same values that are set after we manually modify the font information before loading the font but this should render most of the hack redundant! Is there an ETA for 5.7.0? 🙂

[robmadole]

@hampustagerud we will probably be releasing 5.7.0 this week but don't hold my feet to the fire on that one.

[hampustagerud]

@robmadole That was sooner than I expected anyways, sounds awesome (😬)! Thanks for the reply and hard work put into the font!

[tagliala]

Font Awesome 5.7.0 has been just released. Could you please test and provide feedback?

[hampustagerud]

I can confirm that the numbers are now correct on iOS which now seems able to distinguish between the fonts by choosing Thin, Regular or Bold font 🙂

Thank you @tagliala and @robmadole, this issue seems resolved 🙌