https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Luke Hutchison luke.hutch@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |luke.hutch@gmail.com
--- Comment #22 from Luke Hutchison luke.hutch@gmail.com --- Korean text renders fine in Droid Sans, but not with Droid Sans Fallback. Does Droid Sans contain fully-composed Korean characters, or is it falling back to a font like Noto rather than Droid Sans Fallback?
The google-droid-sans-fonts package is depended upon by many packages on Fedora, so removing the entire package is often simply not an option.
What is the best fix?
1. Removing DroidSansFallbackFull.ttf from the google-droid-sans-fonts package
2. Removing the jamo from DroidSansFallbackFull.ttf
3. Copying the fully-composed Korean characters from Droid Sans (or whatever font it is falling back to, e.g. Noto) into DroidSansFallbackFull.ttf
4. Copying any useful fallback characters in DroidSansFallbackFull.ttf into DroidSans.ttf
Broader questions: Why does font rendering fall back to a font that doesn't even contain the required fully-composed Korean characters? Is the font determined valid for fallback simply because it contains jamo, even though it doesn't contain fully-composed Korean characters? What library makes the font fallback decisions these days, based on the required glyphs -- is it HarfBuzz or FontConfig or something else?
Surely if Korean font rendering is required, a font that contains jamo but not full characters should only be selected if it is the only font on the system that has any sort of Korean characters at all.
i18n-bugs@lists.fedoraproject.org