On Wed, Nov 19, 2003 at 07:37:01PM +0600, Ivan Pascal wrote: > It can be a bug. But I don't know all conditions. Can you give some example > code or just tell what pattern and what locale were used in that case.
LC_CTYPE=fi_FI.UTF-8 all the time. User request: -adobe-helvetica-medium-r-normal-*-12-*-*-*-*-*-iso8859-1 XFontsOfFontset -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso10646-1 -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 Missing character sets, retry with: -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso10646-1, -*-*-medium-r-*-*-12-*-*-*-*-*-*-*,-*-*-*-*-*-*-12-*-*-*-*-*-*-*,* XFontsOfFontSet: -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso10646-1 -misc-fixed-medium-r-semicondensed--12-90-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--12-90-100-100-c-60-iso8859-1 -jis-fixed-medium-r-normal--12-87-100-100-c-0-jisx0208.1983-0 -daewoo-gothic-medium-r-normal--12-87-100-100-c-0-ksc5601.1987-0 -cc-song-medium-r-normal-jiantizi-12-87-100-100-c-0-gb2312.1980-0 -misc-fixed-medium-r-normal--12-87-100-100-c-0-jisx0201.1976-0 The Xutf8 uses the fixed font now. It apparently uses preferred character set list generated with create_tocs_conv (lcUTF8.c), which has iso10646-1 only as a fallback, while the Xmb routines use a preferred list generated with create_tofontcs_conv that does some XLC_FONTSET lookup, and prefers iso10646-1. The preferred encoding list for Xutf8 routines seems to be ISO8859-1 JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 JISX0201.1976-0 ISO10646-1 while for Xmb ISO10646-1 ISO8859-1 ISO8859-1 JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 JISX0201.1976-0 exactly the encodings of the fontset above. But I'm not sure if this is really that information. Maybe the information consists of the character sets in all fontsets? In the above example, if I use the original request pattern at the beginning of the new request, the fixed iso8859-1 font doesn't get loaded but helvetica does and the Xutf8 routines seem to work correctly, except for the potential missing character sets which I did not have this time. Depending on what XLC_FONTSET information actually is, some kind of cross between the two routines (use the XLC_GENERIC list to order the preferred list so that iso10646-1 is a fallback, depending on the locale, of course, but filter with the fontset information) might be a partial solution to this. But there's still the problem if the user wanted a font of which there's only an iso10646-1 version and for this the ordering of character sets in the original request pattern would be needed.. But the utf8tocs and other routines actually seem to get passed what seems like an arbitrary argument array in which the chosen character set is also returned, so maybe the used fontset could actually be passed to and used there without any big modifications, all depending on whether the fontset contains any usefull information. This I think should be the case if XCreateFontSet ordered the fonts more according to the request. > It requires deeper redesign of i18n Xlib's part. > But I think most of modern applications don't use Xlib's output methods for > i18n texts. Therefore such redesign doesn't seem useful. *Sigh*. There are apps beyond "modern" (hah) WIMP and bloated WIMP toolkits. Why must what is broken in Xlib be reinvented and fixed in applications and toolkits when it is just the implementation, not design (ok, that can be argued) that is broken? Are the Xft routines broken as well? Not that I would want to use them. I like the unblurred X fonts. -- Tuomo _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
