On UWP, custom fonts are referenced with a string like "/Path/to/font.ttf#Font name" where the path is relative to the app's install path. This is problematic for a few reasons, listed below.
Request: Allow developers to configure a mapping of Font Name to "path#Name" string as part of React Native Windows initialization. When a fontFamily style is set, look up and, if available, use the value from the map when constructing the XAML FontFamily instance.
Motivation
On iOS, custom fonts added to an RN app can be referenced by their name. On Android, they can be referenced by the file name without the extension, which can typically be made to match the font name. This allows components that use the fontFamily style to be fairly portable.
On UWP, custom fonts are referenced with a string like "/Path/to/font#Font name". This string does not match iOS or Android, and is unique to the consuming application's folder structure, making it non-portable.
An app might workaround this by replacing fontFamily usages within its codebase with a helper function to generate the correct string. Shared component library authors with default font styles might add helper functions or a registration system themselves. Either case invites unique implementations rather than consistency across the platform. Building a solution into RNW directly would alleviate this problem.
Proposal: Add FontFamily registration system
Summary
On UWP, custom fonts are referenced with a string like "/Path/to/font.ttf#Font name" where the path is relative to the app's install path. This is problematic for a few reasons, listed below.
Request: Allow developers to configure a mapping of Font Name to "path#Name" string as part of React Native Windows initialization. When a
fontFamily
style is set, look up and, if available, use the value from the map when constructing the XAML FontFamily instance.Motivation
On iOS, custom fonts added to an RN app can be referenced by their name. On Android, they can be referenced by the file name without the extension, which can typically be made to match the font name. This allows components that use the
fontFamily
style to be fairly portable.On UWP, custom fonts are referenced with a string like "/Path/to/font#Font name". This string does not match iOS or Android, and is unique to the consuming application's folder structure, making it non-portable.
An app might workaround this by replacing fontFamily usages within its codebase with a helper function to generate the correct string. Shared component library authors with default font styles might add helper functions or a registration system themselves. Either case invites unique implementations rather than consistency across the platform. Building a solution into RNW directly would alleviate this problem.
Basic example