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

GdipGetFontCollectionFamilyList does not correctly identify font families #692

Open
trungnt2910 opened this issue Feb 8, 2021 · 0 comments · May be fixed by #693
Open

GdipGetFontCollectionFamilyList does not correctly identify font families #692

trungnt2910 opened this issue Feb 8, 2021 · 0 comments · May be fixed by #693

Comments

@trungnt2910
Copy link

trungnt2910 commented Feb 8, 2021

I am embedding the Open Sans font family (downloaded on Google Fonts) in my Windows Forms application.

To use these fonts, I've added each .ttf file to a PrivateFontCollection. After adding these fonts, I display all the font families by showing string.Join("\n", fontCollection.Families.Select(f => f.Name)).

On Windows, using .NET Framework 4.8, it correctly displays 4 Font families:

Open Sans
Open Sans ExtraBold
Open Sans Light
Open Sans SemiBold

(None of the Windows applications seem to recognize ExtraBold, Light, SemiBold as the same font family).

However, using the latest version of Mono, with the latest build of libgdiplus fetched from master, on Ubuntu 20.04, it shows:

Open Sans
Open Sans
Open Sans
Open Sans
Open Sans
Open Sans
Open Sans
Open Sans
Open Sans
Open Sans

(One different family for each font, although the library correctly recognize them all as Open Sans).

This makes my app unable to distinguish between Open Sans variants on Linux.
Also, creating a Font with one of these families, and applying FontStyle.Bold has no effects.

@trungnt2910 trungnt2910 linked a pull request Feb 9, 2021 that will close this issue
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

Successfully merging a pull request may close this issue.

1 participant