[奇怪] XMMS 的字全亂掉了...

[Tetralet]

最近在一台機器上安裝 Sarge，
基本上是沒啥大問題，
除了所有的 gtk+ 1.2 based 的程式都無法正確顯示中文...

如圖，
在 zh_TW.UTF-8 下執行的 XMMS：
　
字全變成亂碼。

但在 en_US.UTF-8 下執行的 XMMS：
　
卻又是好好的。

在 zh_TW.Big5 及 zh_CN.UTF-8 下執行的 XMMS 也很正常，沒有問題，
但是在 ja_JP.UTF-8 下的 XMMS 也是壞的。

試著找過原因，
似乎是 gtk+ 1.2 based 的程式不認得 zh_TW.UTF-8 這個 Locale，
所以使用了 Unicode 編碼的字型來顯示以 Big5 編碼的文字，
因而導致所有的文字全成了亂碼。

但試過了種種方式，如：重建 locales 等等，
還是無法解決這個問題，
只好向板上的諸位先進求教了...

[caosheng]

cp /etc/gtk/gtkrc.zh_TW /etc/gtk/gtkrc.zh_TW.utf-8

我用這個方法在sarge下目前是可以的

[Tetralet]

cp /etc/gtk/gtkrc.zh_TW /etc/gtk/gtkrc.zh_TW.utf-8

我用這個方法在sarge下目前是可以的

非常感謝您的提醒！

依您的方法，
在 XMMS 上的確可以看到中文介面沒錯，
但此時（在我的系統上）所顯示的是 ETEN Big5 字型，
所以大部份的日文字都無法顯示；
同時，原本以 Unicode 編碼的檔案名稱現在很多都成亂碼了。

看來是 gtk+ 1.2 多事，
把 Unicode 文字又再轉回去 Big5 編碼了。


但如果是 cp /etc/gtk/gtkrc.zh_CN /etc/gtk/gtkrc.zh_CN.utf-8 的話，
在 zh_CN.UTF-8 下的 XMMS 的字又全亂了...
（也就是說，您的方法似乎是僅限於繁體中文環境）

且奇怪的是，
在 en_US.UTF-8 下又完全沒有類似的問題...


這會不會是 gtk+ 1.2 的 Bug 呢？

[阿信]

gtk 讀取 home user 的檔案

lstat64("/etc/gtk/gtkrc.zh", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/etc/gtk/gtkrc.zh_TW", {st_mode=S_IFREG|0644, st_size=614, ...}) = 0
open("/etc/gtk/gtkrc.zh_TW", O_RDONLY) = 4
read(4, "# $(gtkconfigdir)/gtkrc.zh_TW\n#\n"..., 4000) = 614
read(4, "", 4000) = 0
close(4) = 0
lstat64("/etc/gtk/gtkrc.utf8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/etc/gtk/gtkrc.utf-8", {st_mode=S_IFREG|0644, st_size=197, ...}) = 0
open("/etc/gtk/gtkrc.utf-8", O_RDONLY) = 4
read(4, "style \"default-text\" {\n fo"..., 4000) = 197
read(4, "", 4000) = 0
close(4) = 0
lstat64("/etc/gtk/gtkrc.zh.utf8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/etc/gtk/gtkrc.zh.utf-8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/etc/gtk/gtkrc.zh_TW.utf8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/etc/gtk/gtkrc.zh_TW.utf-8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/etc/gtk/gtkrc", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.zh", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.zh_TW", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.utf8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.utf-8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.zh.utf8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.zh.utf-8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.zh_TW.utf8", 0xbffff5cc) = -1 ENOENT (No such file or directory)
lstat64("/home/asho/.gtkrc.zh_TW.utf-8", {st_mode=S_IFREG|0644, st_size=213, ...}) = 0
open("/home/asho/.gtkrc.zh_TW.utf-8", O_RDONLY) = 4

可以看到xmms不會去search gtkrc.zh_TW.UTF-8 檔案，由於我是 zh_TW.UTF-8 的環境，我是採用二樓的仁兄然後改用 new sung 的字體來顯示unicode的部份，當然日文也是正常的摟。

style "default-text" {
fontset = "-misc-ar pl new sung-medium-r-normal--16-*-*-*-c-*-iso10646-1,-monotype-times new roman-medium-r-normal--16-*-*-*-p-*-iso8859-1"
}

class "GtkWidget" style "default-text"

除非字型有缺字，不然都會顯示出來，先前 unicode那一篇小弟也有提及到xmms會出現韓文字體的情況，裝了 ttf-baekmuk 等韓文字體會有這樣的情況，OpenOffice也有出現，可是小弟也不清楚系統是如何叫替字體的順序，或是說CJK處理方面有些priority的問題呢？

弟在這方面涉獵很淺，還請了解的朋友補正和指教.

[Tetralet]

千辛萬苦後的最新進展：

把 xlibs-data downgrade 至 4.3.0.dfsg.1-6，
問題就神奇得消失了，
不管是 zh_TW.UTF-8、zh_CN.UTF-8、ja_JP.UTF-8，
都不會出現任何的亂碼了。

至於 xlibs-data 到底是出了什麼問題，
可能還要再好好研究一下了...

[Tetralet]

後來發現到，
是 /usr/X11R6/lib/X11/locale/zh_TW.UTF-8/XLC_LOCALE 這個檔案出了問題，
（/usr/X11R6/lib/X11/locale/ja_JP.UTF-8/XLC_LOCALE 也是壞的）
換回舊的就好了...

看來可以放心得提出 reportbug 了。
（雖然個人提的 reportbug 沒有幾次是成功的...）

[Tetralet]

先前 unicode那一篇小弟也有提及到xmms會出現韓文字體的情況，裝了 ttf-baekmuk 等韓文字體會有這樣的情況，OpenOffice也有出現，可是小弟也不清楚系統是如何叫替字體的順序，或是說CJK處理方面有些priority的問題呢？

我對此也只是略知一二，
也許得呼喚 Edward G.J. Lee 兄 來回答這個問題了。

但一般而言，
除非系統找不到可對應的字型，（像是 KDE 系列，找不到就留白）
或是該程式根本不支援 i18n，（像是 Adobe Acroread(?)）
否則應該不太會出現亂碼的情況。

如果出現了亂碼，
出現的也應該是 ASCII 碼，（表示它們不支援 MultiByte）
而不該是像韓文之類另一個國家的文字。

而若一個程式竟出現了韓文之類另一個國家的文字時，
就表示該程式所使用的編碼或字型完全錯誤。

以這次的 XMMS 為例，
它使用了以 utf8 編碼的 unifont 來顯示 Big5 文字，
而這基本上是不該發生的...

不過我覺得這些都是 Case by Case 的，
只能說發現出了問題再想辨法解決了...

[Tetralet]

後來發現到，
是 /usr/X11R6/lib/X11/locale/zh_TW.UTF-8/XLC_LOCALE 這個檔案出了問題，
（/usr/X11R6/lib/X11/locale/ja_JP.UTF-8/XLC_LOCALE 也是壞的）
換回舊的就好了...

看來可以放心得提出 reportbug 了。
（雖然個人提的 reportbug 沒有幾次是成功的...）

這個問題己於 xlibs-data 的 4.3.0.dfsg.1-12 中解決。

敝人的 /etc/gtk/gtkrc.utf-8 如下，請參考：

代碼: 選擇全部

style "default-text" {
       fontset = "-sony-fixed-medium-r-normal--16-150-75-75-c-80-iso8859-1,\
                  -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1"
}

class "GtkWidget" style "default-text"

另，/usr/X11R6/lib/X11/locale/ja_JP.UTF-8/XLC_LOCALE 還是壞的，
已經繼續進行 reportbug，
不知 Debian 的 xlibs-data 的 Maintainer 是否會接受就是了...

[訪客]

让xmms播放列表里显示正确的中文
-*-*-*-*-*-iso8859-1,-misc-simsun-medium-r-normal--12-*-*-*-*-*-gbk-0,*-r-
把这个东西完全拷贝到你的字体里面
操作方法:
右键单击xmms播放工具的任何地方
会看到一个"选项",然后选择"功能设定"选择"fonts"
然后把上面的字体完整的拷贝到"播放清单"和 "user x font


對岸找來的 試了一下發現可以用耶 比起我找字型找半天簡單多了原來人家幫我寫好了 呵 這就是我喜歡LINUX的原因

[Tetralet]

這是另一個高度相關的 Bug Report：

　　changes the fontset order in XLC_LOCALE for UTF-8 locale

因為找不到支援 UTF-8 的字型，
所以讓 UTF-8 的 Locale 優先取用其它的字型？

感覺上這個 Bug Report 的建議似乎並不太恰當耶...

[Tetralet]

似乎是找到原兇（笑）了：

　xlibs-data: add ISO 10646-1 character set support to ja_JP.UTF-8 XLC_LOCALE data

是因為這個 BugReport 反而將 zh_TW.Big5 的 XLC_LOCALE 給搞爛掉的嗎？

可惜敝人的功力太差，
根本不明暸那個 Patch 所造成的影響...

還是說那個 BugReport 沒錯，
其實是敝人在搞不清楚狀況...

版上諸先進能否指點呢？

[Tetralet]

這個問題已於 xlibs-data (4.3.0.dfsg.1-13) 中解決，
只要把 xlibs-data 昇級至 unstable 即可。

以下為其說明：

代碼: 選擇全部

Revert XLC_LOCALE/zh_TW.UTF-8 to the version shipped in 4.3.0.dfsg.1-6.
Tetralet explained that Chinese users are likely to have the unifont package installed because it is part of Chinese tasks,
and this font covers all needed glyphs.
With this font, having ISO10646 listed first in this file is harmless,
whereas GTK1.2 apps are unreadable when it is at the bottom of this file.  (Closes: #296719)

事情肇因於一個日本的 Debian 使用者回報說，
因為沒有完整支援 Unicode 的字型，
所以不該把 Unicode 的字集擺到第一位。

這個 ReportBug 想當然是有問題的，
但是 Debian 的 XFree86 的 Maintainer(?) 卻在第一時間接受了這個 Patch。
（要是我們的中文 Patch 都有這種待遇就好了...）
可是不知為何，
這個 Patch 不僅僅把日文的 XLC_LOCALE 給改壞了，
繁體中文也同時遭殃。

於是我也做了 ReportBug，
指出就算是日文字也可以支援 Unicode 字集的，
所以不該接受那個 Patch；
而 ttf-kochi-gothic 和 ttf-kochi-mincho 的 defoma hints 設定有些小小問題，
所以對於 UTF-8 字集才會支援不良。
那個日本的 Debian 使用者也回覆說，
其實他對此也不是很清楚，那個 Patch 是抄自 RedHat 的。

然後 Denis Barbier（Debian 的 XFree86 的 Maintainer(?)）回覆說，
因為在 Chinese tasks 中會安裝 unifont 這個套件；
而在 Japan tasks 裡則沒有，
所以他贊同應該回復繁體中文的設定，
而日文就維持原樣吧...

我本來想回覆說，
日文也可以支援 UTF-8 字集的，
只是設定上的問題...
但是這畢竟應該是那位日本人該負責的事，
我似乎不該去越俎代庖的...
但是那位日本人則一直沒出聲。

於是，繁體中文的 XLC_LOCALE 是修好了，
但日文的 XLC_LOCALE 還是壞的。

事情就是這樣子了...（笑）

我的 /etc/gtk/gtkrc.utf-8 如下，
請參考：

代碼: 選擇全部

style "default-text" {
       fontset = "-gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1"
}

class "GtkWidget" style "default-text"

請不要忘了安裝 unifont 套件哦～～

[nxu]

Gtk+ based 又爆了，原本可以用，所有中文字都正常，結果剛apt-get update，apt-get upgrad(unstable)，就爆了，中文都變成口口口口
請問怎麼救啊？

sorry，又來問問題了。

[Tetralet]

Gtk+ based 又爆了，原本可以用，所有中文字都正常，結果剛apt-get update，apt-get upgrad(unstable)，就爆了，中文都變成口口口口
請問怎麼救啊？

sorry，又來問問題了。

請問您的 Locale 是？
而您的 /etc/gtk/gtkrc.zh_TW 及 /etc/gtk/gtkrc.utf-8 的內容為何呢？

[nxu]

我的locale是英文，(其實是none)
設定如下
export LC_CTYPE=zh_TW.UTF-8
#export GTK_IM_MODULE="gcin"
export XMODIFIERS="@im=gcin"
gcin &
esd -nobeeps -d /dev/dsp &
. /etc/X11/Xsession

gtkrc.utf-8如下
tyle "default-text" {
fontset = "-gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1,\<====這個是我要測別的字型是否也會變方塊時加的。 -*-arial-medium-r-normal--*-180-*-*-*-*-iso10646-1,\
-arphic-ar pl new sung-medium-r-normal-*-22-*-*-*-m-*-big5-0,\<==沒upgrade以前可正常看到中文 -*-helvetica-medium-r-normal--*-180-*-*-*-*-*-*"

}

class "GtkWidget" style "default-text"

這是zh_tw的完全沒動它 哈哈
style "gtk-default-zh-tw" {
fontset = "-adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1,\
-taipei-*-medium-r-normal--*-*-*-*-*-*-big5-0,\
-*-*-medium-r-normal--16-*-*-*-*-*-big5-0,*-r-*"
}
class "GtkWidget" style "gtk-default-zh-tw"

麻煩賜招了。Orz...