OpenSolaris

Printable Version Enter a New Search
Bug ID 6477134
Synopsis FcFontMatch doesn't work for monospace on ja_JP.UTF-8 after nv_49
State 10-Fix Delivered:Verified (Fix available in build)
Category:Subcategory xserver:font
Keywords s10u3-reviewed
Responsible Engineer Jay Hobson
Reported Against snv_49
Duplicate Of
Introduced In solaris_10u3
Commit to Fix snv_51
Fixed In snv_51
Release Fixed solaris_nevada(snv_51) , solaris_10u3(s10u3_09) (Bug ID:2142707)
Related Bugs
Submit Date 2-October-2006
Last Update Date 16-January-2007
Description
If fc-match command bundled in fontconfig is invoked with monospace
on ja_JP.UTF-8 locale, "HG-GothicB-Sun" font was displayed as best
much font until nv_b48.
===
% ./fc-match monospace
hggbsun.ttf: "HG-GothicB-Sun" "Regular"
===
However, "Lucida Sans Typewriter" is displayed after b49. 
===
% ./fc-match monospace
LucidaTypewriterR13.pcf: "Lucida Sans Typewriter" "Medium"
===
If --sort option is used, it works fine. So it looks that
FcFontSort works fine but FcFontMatch doesn't. 

I encountered that Japanese characters in some area are rendered by non-Japanese 
fonts with thunderbird or firefox on b49. I think that it is caused by this 
issue because this problem doesn't occur if the following code in 
src/fcmatch.c is commented out or workaround applied.
===
/*
            if ( ls )
            {
                FcValue patLang;

                for (i = 0;
                     FcPatternGet (p, FC_LANG, i, &patLang) == FcResultMatch;
                     i++)
                        ;
                if ( FcPatternGet ( p, FC_LANG, i-1, &patLang) == FcResultMatch
)
                    score[MATCH_LANG_INDEX] = FcHidePoorLangs ( &patLang, ls );
                FcLangSetDestroy ( ls );
            }
*/
Work Around
Comment out the following with using "<!--" and "-->" in fonts.conf.

<alias>
        <family>Monospace</family>
        <poor>
                <family>Lucida Sans Typewriter</family>
                <lang>ar</lang>
        </poor>
</alias>
Comments
N/A