Replies: 2 comments
-
|
also I've noticed a notable diffence in the typeface loading on windows and linux while testing. Linux: Windows: Same code, same font file, different results, linux seems to load fonts entirely differently. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I think its issue with SkiaSharp or native deps of the SkiaSharp |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I’m experiencing inconsistent behavior with custom font loading in SkiaSharp when rendering SVG files across different platforms (Windows and Linux). On Linux, custom fonts are registered and loaded successfully by a custom ITypefaceProvider, but the rendered output still uses some default font (DejaVu Sans) instead of the intended custom fonts. On Windows, the same code works as expected, rendering the custom fonts correctly. Something is clearly frong in the process of loading fonts.
I've looked at other issues opened here, researched the soure code and looked on other websites like stackoverflow but nowhere this specific issue was described. That's why I'm creating this issue.
Environment:
Steps to Reproduce:
Expected Behavior:
The output PNG should use the custom fonts (Akira Expanded, Delecta, etc.) as specified in the SVG and registered by the CustomTypefaceProvider on both platforms.
Actual Behavior:
Windows: Custom fonts are rendered correctly in the output PNG.
Linux: Despite the fonts being registered and loaded (confirmed by logs), the output PNG uses the default font DejaVu Sans. Logs show SkiaSharp attempting to load Akira Super (not registered) and falling back to DejaVu Sans.
Logs (Linux):
The logs show that Akira Expanded is registered and loaded multiple times successfully (Loaded: Akira Expanded), indicating the CustomTypefaceProvider works.
However, SkiaSharp then requests Akira Super (which isn’t registered) and falls back to DejaVu Sans. This suggests a mismatch between what the SVG requests and what the provider supplies, but only on Linux.
Additional Notes:
Fonts are readable and valid on Linux (permissions checked with chmod +r).
libfontconfig1 is installed and functional (fc-list works).
Hardcoding absolute font paths doesn’t resolve the issue.
Test project:
I will also attach a test visual studio project containig code and used svg files which reproduces the specified issue when running on linux.
TestFamilyNames.zip
Beta Was this translation helpful? Give feedback.
All reactions