https://bugzilla.redhat.com/show_bug.cgi?id=2262410
--- Comment #24 from Oleg Oshmyan <chortos(a)inbox.lv> ---
> Fontconfig doesn't remove the font from the complete font
list seen by libass
No, not exactly. What libass does is to obtain *all* the font list for sans-serif no
matter what coverage they are. As I said earlier, libass has an own function to filter out
fonts.
The list returned by Fontconfig is ordered by priority. libass uses the first
(highest-priority) font that satisfies the request. The choice of priority lies
entirely with Fontconfig.
Then, libass looks up this font in the full list of fonts installed on the
system, which includes Arabic fonts regardless of locale, because it does want
to be able to render Arabic files on any system.
Again, Noto Sans Arabic doesn't have "en" coverage and
isn't supposed to be used for Latin characters in theory, regardless of whether there
are lang="ar" line or not, *except* applications do the special things.
But Latin *isn't the problem*. It's digits. Noto Sans Arabic contains digit
glyphs. When it is the system's default font, applications have no reason not
to use those glyphs.
Application says: draw this number in sans-serif
Fontconfig says: the top sans-serif font is Noto Sans Arabic
libass says: OK, here's your number set in Noto Sans Arabic
libass doesn't support variable fonts well then.
libass doesn't support variable fonts at all, except in a few edge cases where
Fontconfig makes them look like dedicated physical fonts.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2262410
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...