https://bugzilla.redhat.com/show_bug.cgi?id=2262410
--- Comment #32 from Akira TAGOH <ta...@redhat.com> --- (In reply to Oleg Oshmyan from comment #31) > No, I mean fonts that are designed to support a single language. A font > _can_ provide good support for everything at once via GSUB, but such global > support isn't all that common and more often you find that you have e.g. a > Japanese font, a mainland Chinese font and a Hong Kong Chinese font with > near-identical glyph coverage but different shapes. My impression has been > that this is (at least part of) why fonts.conf allows specifying what > languages a font should be preferred for. Well, because Unicode unified similar shapes. we can't guess a language from a character coverage completely, particularly if it is all-in-one font. > Indeed, Noto Sans itself is a counterexample. I don't understand why it > isn't all a single font, but it isn't: instead, we have a myriad of > language-specific fonts with distinct names. It isn't that simple. Such all-in-one font has another problem. As you can see in the file picker in plasma, character width and height may be too wider/taller because it will be aligned to the most widest/tallest one for fixed font and monospace, or just for better looking. also, they won't be recognized as monospace because they have too many size of glyphs. > > > 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. > > This might be useful when a lang L is requested, but again, the case here > doesn't request any particular language at all. All we know is that we need > "the `sans-serif` font". Yes, that's right. so what's wrong so far? fontconfig returns all sans-serif fonts *as* requested. there are nothing wrong there. other tasks are up to libass. > We could explicitly fetch the current system locale > in libass and ask Fontconfig to look for this language, but I guess we kinda > expected that Fontconfig already does this for substitutions/aliases on its > own. No, as I noted, current usage of the results from FcConfigSubstitute() is completely wrong. otherwise fontconfig doesn't need to provide APIs such as FcFontMatch/FcFontSort at all. -- 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%23c32 -- _______________________________________________ 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
