https://bugzilla.redhat.com/show_bug.cgi?id=2262410
--- Comment #30 from Akira TAGOH <ta...@redhat.com> --- (In reply to Oleg Oshmyan from comment #28) > Ah, you must mean the other kind of lang object, the one Fontconfig extracts > from each font. I'm actually unsure how it does this; isn't it still built > from the fonts' built-in code page or Unicode coverage bits? Anyway, I don't > see how that helps. There are one in SFNT table right. but no, it isn't. As I said, the lang object in fontconfig is estimated from the real charset coverage loosely. > And more than anything, fonts' language properties are useful to determine > what shape the glyphs have rather than what glyphs are available. For > example, some CJK code points look different in different variants of > Chinese and Japanese, some Cyrillic code points look different in Bulgarian, > Serbian and Russian, and even some Latin code points look different in > Europe and elsewhere. Correspondingly, if one knows the text being rendered > is in a particular language, one should prefer a font that is designed for > that language. Well, that is different thing. they are assigned to the same codepoint but have different shape with GSUB. fontconfig doesn't get involved with the rendering thing at all. it is out of the scope. > But this doesn't mean that one should stop checking whether a glyph actually > exists in a font, and when no particular language is involved, libass has no > particular reason to look for an English font when another font fits the > bill. I'm not sure what is correct but what if: a. font A is missing a glyph X only in a unicode code block M b. font B has full coverage for M c. font A is somehow coming first In current implementation, a glyph X will be rendered with font A and others with B. I think this is what is actually happening at libass. However, given that X is key codepoint to represent lang L, it can be simplified because: a. font A is missing a glyph X so it doesn't satisfy lang L. b. font B has full overage for M so it satisfies lang L. c. font B will be picked up if requesting lang L. > > It isn't actually "ordered by priority". FcPattern built by > > FcConfigSubstitute() is just a result going through all config enabled. > > There are nothing more than that. > > It doesn't guarantee that it is available on the system even. > > fontconfig tries to build a best font/font list with FcFontMatch/FcFontSort > > against it. the result will be polished. This is what libass is missing > > here. > > Side note: it would help if Fontconfig documentation actually explained this. Sure. > So basically we just need to add a FcFontSort call immediately after the > FcConfigSubstitute? with FcDefaultSubstitute() too. > How *does* Fontconfig decide to prefer Noto Sans upon FcFontSort in this > case? Does it try to find a font that covers the system locale's language? That depends how one requests with FcPattern. the system locale is one of hints what characters they may want to see. If applications has multilingual support and they know what a language they are, they could set it instead of the system locale of course. You could check "fc-match -s :lang=XX" with the lang code XX. this calls FcFontSort. for example: $ fc-match -s :lang=en | head -3 NotoSans[wght].ttf: "Noto Sans" "Regular" NotoSans-Italic[wght].ttf: "Noto Sans" "Italic" NotoSansArabic[wght].ttf: "Noto Sans Arabic" "Regular" $ fc-match -s :lang=ar | head -3 NotoSansArabic[wght].ttf: "Noto Sans Arabic" "Regular" Vazirmatn[wght].ttf: "Vazirmatn" "Regular" NotoSans[wght].ttf: "Noto Sans" "Regular" $ fc-match -s :lang=ja | head -3 NotoSansCJK-VF.ttc: "Noto Sans CJK JP" "Regular" NotoSans[wght].ttf: "Noto Sans" "Regular" NotoSans-Italic[wght].ttf: "Noto Sans" "Italic" $ fc-match -s :lang=hi | head -3 NotoSansDevanagari[wght].ttf: "Noto Sans Devanagari" "Regular" NotoSans[wght].ttf: "Noto Sans" "Regular" NotoSans-Italic[wght].ttf: "Noto Sans" "Italic" (In reply to Oleg Oshmyan from comment #29) > Seeing the __libass_delimiter magic though, I suspect this isn't quite that > easy. I don't know what is it for? -- 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=report-spam&short_desc=Report%20of%20Bug%202262410%23c30 -- _______________________________________________ fonts-bugs mailing list -- fonts-bugs@lists.fedoraproject.org To unsubscribe send an email to fonts-bugs-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/fonts-bugs@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
