Bug 7 - Improve handling of fallbacks from generic aliases
Summary: Improve handling of fallbacks from generic aliases
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.1
Hardware: x86 (IA32) Linux (All)
: high enhancement
Assignee: Keith Packard
QA Contact:
URL: https://bugzilla.redhat.com/bugzilla/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-14 14:05 UTC by Owen Taylor
Modified: 2015-05-01 19:54 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

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
cvcvsddvdcvsdvdsvzcxvsdvsdv
Comment 6 Behdad Esfahbod 2015-05-01 19:54:13 UTC
Why was this reopened?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.