Hi, I've found a strange problem that I believed to be caused by fontconfig. On my RedHat 8.0 box, I added MS-Windows font path at the top of font dir. list in fonts.conf. That directory has CODE2000.TTF(http://home.att.net/~jameskass) and 'New Gulim' (from MS's old Korean support tool: http://officeupdate.microsoft.com/korea/downloaditems/2000/OHFonts.exe. You can extract the file under Linux using cabextract at http://www.kyz.uklinux.net/cabextract.php3). For some unknown reason, 'New Gulim' is picked up by 'fontconfig' or 'Xft' for a certain characters when CODE2000 is explicitly requested by applications like Mozilla and gedit (via Pango) More specifically, those certain characters are U+115F(Hangul leading consonant filler) and U+1160(Hangul trailing consonant filler). There might be other characters for which fontconfig(or Xft) overrides the explicit "user" request. (btw, U+115F and U+1160 were added to the blank char. list in /etc/fonts/fonts.conf. This and putting Windows font path at the top of font dir. list are the only chanages I made in fonts.conf)
Both CODE2000 and New Gulim have glyphs for those two characters. However, I certainly want to use glyphs from CODE2000 because they have desired 'spacing' behavior. I can't readily figure out why fontconfig is handing back 'New Gulim' instead of CODE2000 for U+115F and U+1160 while honoring 'user' (consumer of fontconfig and Xft) request for other characters in U+1100 block. Could it be related to lang/locale based font selection mechanism ? However, my test under en_US.UTF-8 locale sorta ruled out that possibility (not completely, though). I ran my test(gedit and Mozilla) under ko_KR.UTF-8 locale. Anyway, it's strange that my request for CODE2000 is honored for all other characters in U+1100 block while U+115F and U+1160 are rendered with New Gulim. CODE2000 has a very wide coverage of Unicode characters including U+1100 Hangul Jamos(inclduing those two fillers). Glyphs for Hangul Jamos in CODE2000 are designed in such a way that a simple-minded over-striking works in rendering Conjoining Hangul Jamos. (i.e. Leading consonants are advancing/spacing while vowels and trailig consonants are zero-width/non-advancing.) On the other hand, glyphs for U+1100 Hangul Jamos in New Gulim are all spacing/advancing and not suitable for rendering of Hangul Jamos. You may wonder how I'm so sure that 'New Gulim' is used instead of 'CODE2000'. There are two pieces of 'evidence'. One is the difference in the way <http://jshin.net/i18n/korean/hunmin.html> is rendered by Mozilla-Xft(under Linux) and MS IE6. (Mozilla under MS Windows is less suitable for comparison because the bug I filed for blank glyph list has not been yet fixed in Mozilla for MS Windows and U+1160/U+115F is rendered as a question mark.). Two screenshots are put up at http://jshin.net/i18n/korean/hunmin_comp.html You'll see the spacing between the first character(after the bullet) and the second character is much wider in Mozilla-Xft's rendering than in MS IE's rendering. The sequence rendered is '<bullet> U+1100 U+1160 U+1102 U+11AE U+11AA'. Both are supposed to use CODE2000. Mozilla-Xft uses CODE2000 for all other characters except for U+115F and U+1160. The glyph for U+1160 in New Gulim is spacing and that's why Mozilla-Xft's rendering has much wider gap between U+1100 and U+1102 than MS IE's. The other was obtained while I was debugging Pango Hangul-xft module I've been working on.(http://bugzilla.gnome.org/show_bug.cgi?id=95708). I want Pango Hangul-xft module to behave differently depending on a font selected. I used pango_xft_lock_face() to get a FT_face object and to figure out family_name. When 'CODE2000' is selected in gedit, the value of family_name is 'CODE2000' most of time, but when it comes to render U+115F and U+1160, it suddenly changes to 'New Gulim'. If I only had the latter info., I would suspect some magic is done in Pango-Xft. However, Mozilla-Xft's similar behavior led me to think that something is going on somehere up the chain (either fontconfig or Xft). This may or may not be right. While I'm trying to dig this out myself, it'd be much appreciated if somebody could shed some light on this. Jungshik _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
