https://bugzilla.redhat.com/show_bug.cgi?id=1833858
Luke Hutchison <luke.hutch(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |luke.hutch(a)gmail.com
--- Comment #22 from Luke Hutchison <luke.hutch(a)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.
--
You are receiving this mail because:
You are on the CC list for the bug.