|Summary:||Improve handling of fallbacks from generic aliases|
|Product:||fontconfig||Reporter:||Owen Taylor <otaylor>|
|Component:||library||Assignee:||Keith Packard <keithp>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
Description Owen Taylor 2003-01-14 14:05:46 UTC
Given the pattern: Monospace-10:lang=ar And the string "ABC" to display with it. You have in your fonts.conf <alias> <family>monospace</family> <prefer> <family>Andale Mono</family> </prefer> </alias> On your system, you have a single font covering Arabic and Roman, "KacstBook", thatisn't even close to monospace. The FcFontSort results will be: KacstBook, Andale Mono, resulting in "ABC" rendered with KacstBook. My contention is that the ordering should be Andale Mono, KacstBook instead. I don't have a good idea about how this would be implemented. What we need is that Lang match vs. Lang no match reorders within weak family matches, but any weak family match beats no weak family match without regard to Lang. Possibly what could be done is to allow instead of two slots in the value array per match element, 3 slots. weak strong any And makethe matchers in addition to returning a numeric result, return whether there was any result at all, and if so, we stick constant value in the any slot. So, then you could order things in the value array as: family strong family any lang family weak Ugly, but it's a real problem. Without something like this, it's really hard to support a meaningful "monospace" alias in a language where monospace fonts don't make sense (like Arabic)
Comment 1 Keith Packard 2003-01-28 13:37:09 UTC
I'm not sure fontconfig can have reasonable hard-coded policy in this case. You can always customize the configuration to ignore the language field for a particular generic->specific mapping if you like by using a strong-binding edit.
Comment 2 Owen Taylor 2003-01-28 13:47:04 UTC
If we just make monospace a strong alias, we lose the reordering-within-the-alias feature, which is no good. So, I don't think that's any sort of solution...
Comment 3 Owen Taylor 2003-02-04 13:29:05 UTC
So, how would you suggest fixing the bug referenced in the URL: field?
Comment 4 Jeremy Huddleston Sequoia 2011-10-12 14:18:39 UTC
Closing old resolved bugs
Comment 5 Aditya 2013-03-20 10:49:33 UTC
Comment 6 Behdad Esfahbod 2015-05-01 19:54:13 UTC
Why was this reopened?