----- Forwarded message from [EMAIL PROTECTED] -----
Delivered-To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug 877] New: UTF8 related font selection is broken & multibyte encoding
disagreement with libc
X-Bugzilla-Reason: Reporter
In-Reply-To: <[EMAIL PROTECTED]>
Date: Mon, 17 Nov 2003 06:13:48 -0500
X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at netsweng.com
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
modeemi.modeemi.cs.tut.fi
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no
version=2.60
X-Spam-Level:
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=877
Summary: UTF8 related font selection is broken & multibyte
encoding disagreement with libc
Product: Client Libraries
Version: 4.3
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: xlib
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Problem 1
Font selection (from a fontset) in the Xutf8* string drawing routines does not
work in a sane manner in any locale and neither does font selection in the
Xmb/Wc* drawing routines in an UTF8 locale. Moreover, the Xmb and Xutf8 routines
do not select fonts consistently in an UTF8 locale.
Example 1. LC_CTYPE=fi_FI.UTF-8, user wants the base font to be
-adobe-helvetica-medium-r-normal-*-12-*-*-*-*-*-iso8859-1. The same font _but
with iso10646-1 encoding_ among some others fonts gets loaded (XCreateFontSet),
guessed with the code available e.g. at
<http://www.debian.org/doc/manuals/intro-i18n/ch-examples.en.html#s13.4>.
(XCreateFontSet fails if only the user specified pattern is passed.)
The Xmb routines never use any other fonts but the iso10646-1 helvetica that
does not contain all characters, because fonts are selected based on first
matching character set and iso10646 seems to be preferred.
Studying the Xlib source code, apparnetly Xmb in UTF8 locale selects fonts by
the order of fonts in the fontset, that does not match the order of fonts in the
request pattern to XCreateFontSet. Shouldn't the pattern matter? Shouldn't the
glyphs actually implemented in a font matter, in particular in case of iso10646
fonts?
Example 2. Same as above, Xutf8 routines. These routines seem to prefer
iso8859-1 encoding and indeed a fixed-width font with that encoding is in the
fontset. But the user wanted helvetica!
It seems Xutf8 routines select fonts from the fontset by a fixed list of
encodings, filtered by the locale. Again, font select based on character set
guess is wrong.
Example 3. Same as above, remove iso10646-1 helvetica from system. Situtation is
reversed. Xmb routines use a fixed-width font, Xutf8 routines helvetica.
Problem 2
All the drawing routines also have the problem of stopping processing the string
when an encoding is selected for which there is no font in the fontset, even if
some font with other encoding might implement the wanted glyph. Once again, font
selection should be based on the available fonts, not the first matching
encoding and there's no need to skip the rest of the string even if a font can't
be found.
Problem 3
This is unrelated to the above two problems, may not necessarily be a bug in
Xlib and I can only say of the situation under Debian/unstable, gnu libc 5.4.46.
The problem is that if there are multiple encodings listed for otherwise the
same locale in /etc/locale.gen and locale-gen has been used to generate whatever
it does, libc mb routines always use the last encoding listed in that file while
Xlib mb routines respect the LC_CTYPE setting. XSupportsLocale succeeds. While
libc may not do the right thing here, it sets the environment and
nl_langinfo(CODESET) can be used to obtain the encoding expected by the libc mb
routines.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
----- End forwarded message -----
--
Tuomo
