Around 12 o'clock on May 28, Olivier Chapuis wrote:
> - The output of xft-config --libs gives: > > -L/opt/Xft/lib -lxft ...etc. Oops. (fixed now). > - First I've compiled your packages with freetype-2.0.6. So there > is no FT_Get_Next_Char function and this function is defined in > fontconfig/src/fccharset.c. It seems that this definition leads to > an infinite loop somewhere. With such build a simple programs as: I haven't tested without FT_Get_Next_Char in quite a while; that function dramatically reduces the time it takes to scan fonts for available glyphs, so it may not be an infinite loop you're seeing, just a long delay. With any reasonable number of fonts (~100), scanning the available fonts can take 15 or 20 seconds. Note that if you've run fc-cache, there shouldn't be a delay. > - XftDrawStringUtf8 does not seem to work. This (and XftTextRenderUtf8) were both broken. > XftDrawString8 assumes that the string "encoding" is iso8859-1 That's only because ucs-1 == iso8859-1; all of the Xft APIs use Unicode encodings. > Can we display other encoding than iso8859-1 (as iso8859-15) > with XftDrawString8? No, but feel free to use iconv, or some other suitable conversion mechanism, when sending data to Xft. I strongly encourage people to use a Unicode encoding internally throughout their applications and perform these conversions when interacting with the file system. UTF-8 requires only a modest amount of additional memory for most western languages. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
