Ivan Pascal <[EMAIL PROTECTED]> writes:
> Owen Taylor wrote:
> > I'm certainly not certain that we shouldn't set up the font sets that
> > way, but some reasons I didn't suggest it were:
> >
> > - There are some strange effects that occur for the user if you
> > list all the font encodings individually with iso10646-1 last.
> >
> > An important one is, if I have, as my fontset specification:
> >
> > -*-arial-medium-r-normal--*-140-*-*-p-*-*-*,
> > -*-helvetica-medium-r-normal--*-140-*-*-p-*-*-*
> >
> > And (for the sake of discussion) say that I have arial in only
> > iso10646-1, but I have helvetica in both iso10646-1 and
> > iso8859-1. Then I'll get Helvetica for iso8859-1 characters,
> > not Arial.
>
> Nothing strange. A fontset creation procedure applies a basename
> list to each charset separately and chooses the first matching font,
> i.e. the font with the first basename from the list for which a
> matched font exists. Thus in your example the creation procedure
> skips an arial for the iso8859-1 encoding and chooses a Helvetica
> font for it but for the iso10646-1 encoding the procedure can find
> the arial font and shooses it for the iso10646-1. On the other hand
> if your encoding list contains the iso8859-1 encoding before the
> iso10646-1 a DrawString procedure tries convert the string to the
> iso8859-1 (and draw it with chosen font) and only if this attempt
> fails it tries other encodings.
I don't mean it is strange in the sense that I don't understand
why it happens. What I mean is that it is strange in the sense
that I don't think it's what users expect or want. :-)
As long as we configure things so that fonts available in iso10646-1
are also available in the subset encodings that are listed before
it, this quirk won't have an adverse impact, but, unfortunately,
I've seldom seen a system where the set of encodings that are
exported for different fonts is sensibly consistent. It's
just too hard to configure.
> > - I've had performance problems with putting long lists of fonts
> > into XLC_LOCALE, especially if the lists of fonts includes CJK fonts.
> > It's possible that there is something broken with the on-demand
> > loading implementation in the XFree86 Xlib.
>
> I think the Xlib itself is not broken. The thing is the on-demand
> loading means that the creation procedure uses the
> XListFontsWithInfo call instead of the XLoadFont. But the
> XListFontsWithInfo needs to open and read the font file (unlike the
> XListFont which need not) and it cause the dealy you see. It seems
> this 'font info' isn't used by the Xlib itself but can be requested
> by an application using the XFontsOfFontSet call.
Ah yes, that makes sense. Not much we can do to optimize this
for the case I'm interested in, since GTK+-1.2, after calling
XCreateFontSet immediately calls XFontsOfFontset and uses
the results to compute an ascent/descent for the fontset.
Regards,
Owen
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
