Font fix for WPF #944
Font fix for WPF #944
Conversation
|
Can this be made more congruent (and/or maybe shared) with the loading of embedded resources in InitialtizeAsync() here: https://github.com/ReactWindows/react-native-windows/blob/fb60d23ea1d6434e2e394ddbd33816f65ca9b33e/ReactWindows/ReactNative.Shared/Bridge/JavaScriptBundleLoader.cs#L98 |
| path = path.Take(path.Count() - 1).ToArray(); | ||
| string cleanPath = "./" + string.Join("/", path) + "/"; | ||
| string[] fontParts = _fontFamily.Split('#'); | ||
| textBlock.FontFamily = new FontFamily(new System.Uri("pack://application:,,,/"), cleanPath + "#" + fontParts.Last()); |
There was a problem hiding this comment.
application [](start = 77, length = 11)
Do you have a pointer to some documentation on this URI? #Closed
|
Scroll to "Referencing Font Resource Items from Code" There's also a corresponding stack overflow answer from similar questions. 100% transparency, I have no clue what secret knock this URI is doing. It's pretty crazy with the "tres comas" - and additional pomp. But it works. My goal was to take any UWP friendly code and make it work for WPF |
|
In addition - Leon will be using this to scan for any other asset related issues. Once we have a large list of asset problems, a more centralized solution might reveal itself. Regardless, the |
|
Could we put the MSDN reference in a comment in the code? In reply to: 270129550 [](ancestors = 270129550) |
|
@rozele - comment added. |
custom fontFamily props were not working in WPF because assets are accessed differently in WPF. This PR re-arranges the string to be consumed by a URI that can properly access and set the
fontFamilyfor text.