Hi,
> > 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
Right. And iso8859-1 fonts are 'helvetica' here.
> Missing character sets, retry with:
> -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso10646-1,
> -*-*-medium-r-*-*-12-*-*-*-*-*-*-*,-*-*-*-*-*-*-12-*-*-*-*-*-*-*,*
But in this patern there is nothing saing that iso8859-1 fonts should be
'helvetica'. Thus it is not a bug.
> 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
Yes. It is a real bug. The create_tocs_conv routine gathers the preferred
charsets list from 'cs*' records of XLC_LOCALE but create_tofontcs_conv
gathers the list from 'fs*' records. The bug is that Xutf8 drawing functions
in UTF-8 locale should use create_tofontcs_conv as Xmb functions do.
But they don't.
If you can rebuild your Xlib you can try a simple fix. Add at the end of
_XlcAddUtf8LocaleConverters (the last procedure in lcUTF8.c) the string:
_XlcSetConverter(lcd, XlcNUtf8String, lcd, XlcNFontCharSet, open_utf8tofcs);
> 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.
The XLC_GENERIC (XLC_LOCALE ?) data and XLC_FONSET data my differ because
the first one is used mainly for utf8 to CTEXT conversion (an in this
conversion iso10646 should be the last charset) but XLC_FONTSET data is needed
for the text drawing.
But I don't think that to-fontset converters should somehow merge them.
All data in the locale description is a static settings and doesn't change
from one to other applications or from one to other call of an application.
If one supposes the XLC_FONTSET data is wrong or incomplete this data should
be fixed. But as I said all drawing functions (Xmb and Xutf8 families)
must use the same converter(s).
> 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..
It's unclear for me. If there is only iso10646 version of the font matched
the base_name, only this font will be loaded and all other charsets become
missing_charsets. How any ordering information can help there?
> 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 isn't a problem to pass the pattern (base_name list) to the converter
(although I think it should be used in create_*_conv procedures rather than
in the converter itself). The problem can be the merging its order with
XLC_LOCALE order. And as I wrote in the previous message the base_name order
become to change somehow the 'locale decription defined' order it can be
considered as unexpected and annoying.
But I think your idea is worth considering.
> > 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
Agree.
> in applications and toolkits when it is just the implementation, not
> design (ok, that can be argued) that is broken?
Saying "design" I meant that iso2022-based i18n support with non-overlapped
charsets doesn't need any charset ordering at all. The lately added 'unicode
support' that uses a mix of iso2022 and iso10646 fonts is a kind of hack.
If this subsystem were originaly designed on the assumption that the charsets
order does matter and should be configured flexibly for each application,
the API would be different.
But I agree that the existent 'hack' can get some improvement. :)
> Are the Xft routines broken as well?
AFAIK Xft deals with unicode encoded fonts only and doesn't use Xlib's i18n
functions. If it even were broken it has no reation to Xlib bugs. :)
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
