Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add font-variation-settings feature for variable fonts #829

Open
davebcn87 opened this issue Nov 5, 2024 · 3 comments
Open

Add font-variation-settings feature for variable fonts #829

davebcn87 opened this issue Nov 5, 2024 · 3 comments

Comments

@davebcn87
Copy link

Introduction

Variable fonts support in React Native is currently limited compared to native iOS/Android and web platforms. While React Native supports variable fonts, it lacks fine-grained control over font variations that designers and developers need.

Web platforms use font-variation-settings to specify custom font characteristics, enabling:

  • Non-standard font weights (e.g., 450 between regular and medium)
  • Custom axes defined by font designers
  • Standard variation axes (weight, width, slant, etc.)
  • Symbol font variations (fill, optical size, etc.)

Details

Both iOS and Android platforms natively support variable font features. We propose exposing these capabilities through React Native's Text component API, matching the CSS implementation pattern.

We've created proof-of-concept implementations for both iOS and Android, supporting both old (Paper) and new (Fabric) architectures.

Implementation examples

  1. Custom Font Weights
<Text 
  style={{
    fontFamily: 'Inter',
    fontVariationSettings: '"wght" 850'
  }}>
  Extra Bold Text
</Text>
  1. Symbol Fonts with Multiple Axes
<Text
  style={{
    fontFamily: 'MaterialSymbolsSharp',
    fontVariationSettings: "'wght' 100, 'FILL' 0",
  }}>
  {String.fromCodePoint(59576)}
</Text>
  1. Multiple Variation Settings
<Text
  style={{
    fontFamily: 'MyVariableFont',
    fontVariationSettings: "'wght' 600, 'wdth' 80, 'slnt' -5"
  }}>
  Custom Text
</Text>

Key Features:

  • Supports all standard variation axes (wght, wdth, slnt, ital, opsz)
  • Allows custom variation axes defined by font designers
  • Compatible with existing font-related style properties
  • Overrides basic font properties when both are specified
  • Works consistently across iOS and Android

Screenshots

Fabric Paper
Simulator Screenshot - iPhone 15 Pro - 2024-05-27 at 10 22 34 Simulator Screenshot - iPhone 15 Pro - 2024-05-27 at 10 36 58

Discussion points

  • Performance impact of parsing variation settings
  • Interaction with existing font style properties
  • How to handle invalid variation settings
  • Documentation updates
  • Support for other platforms other than iOS and Android
@cipolleschi
Copy link

cc. @necolas @elicwhite @cortinico

@stefan-schweiger
Copy link

Just ran into this today. The font weights for variable font with Raleway for example work even now (but on android you need to add a according font.xml). But when using Material Symbols the font weight just won't work on iOS. My only assumption is because I would actually need to set the font-variation-settings. And this is even more painful when you try to use properties like fill etc which have no equivalent in classic css props.

@axyz
Copy link

axyz commented Feb 20, 2025

cc @matinzd @davebcn87 @necolas
Any update on this topic?

I noticed the 2 linked pr do not have any recent activity, and wondering if there are open concerns and the best way forward.
Some high level questions on my side:

  • What is the status? Is the topic stale/abandoned? Are you open to additional contributions? Are there unresolved points to discuss?
  • considering the types and the API of Text is changed, should the 2 PR be merged into a single one?
  • In the current PR only font-variation-settings is added, but not the various aliases available in css (font-stretch, different typing for font-weight, font-optical-sizing) and no additional logic for possibly conflicting properties (font-style). Is there an opinion on React Native side on including the aliases or not, and/or how to handle the conflicts? Is this the reason for not moving forward with the proposed PRs?

We are currently discussing about forking React Native vs Implementing a Fabric Component to replace Text to overcame this issue, and honestly both options are way worse than moving forward with a contribution to React Native, so I'm looking forward to hear your take on the matter, and I'm open to contribute where needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants