打造 Unicode 的環境－藍色情懷

打造 Unicode 的環境

什麼是 Unicode？

　　簡而言之， Unicode 為一 ISO 國際標準，
　　它包含了世界各國的常用文字，目前已收錄有 8 萬(?) 個字以上。
　　它的目的是統一世界各國之編碼，讓世界文字萬碼奔騰的狀況不復出現。

　　　　註：UTF-8 為 Unicode 編碼方式之一，感謝 shogun1234 兄指正！

為什麼要轉入 Unicode 環境？

　　在這個資訊爆發的時代，國際化早就是無法抗拒之潮流。
　　不管是在 Web 上、新聞、郵件、文件中，
　　我們常常遇到必須處理多國文字的狀況。
　　再加上 Big5 中文編碼上的設計缺陷以及字數嚴重不足等等問題，
　　全面轉換至 Unicode 環境似乎是不可避免的...

在 Linux 中，如何轉入 Unicode 環境？

　　請先產生 UTF-8 的 Locales，例：

代碼:

# 在 /etc/locale.gen 中，加入 zh_TW.UTF-8 UTF-8 及其它您所需要的 Locales。
cat >> /etc/locale.gen << EOF

en_US.UTF-8 UTF-8
ja_JP.EUC-JP EUC-JPja_JP.UTF-8 UTF-8
zh_TW.UTF-8 UTF-8

EOF

# 執行 locale-gen 來產生這些 locales 資訊檔。
locale-gen

　　再設定好 Locale 的環境變數，
　　就可以改變現正所使用的 Locale。
　　您可以把這些環境變數寫在 ~/.bashrc、~/.xinitrc 或是 ~/.xsession 中，
　　以 ~/.xinitrc 為例：

代碼:

#!/bin/sh
# $Xorg: xinitrc.cpp,v 1.3 2000/08/17 19:54:30 cpqbld Exp $

# /etc/X11/xinit/xinitrc
#
# global xinitrc file, used by all X sessions started by xinit (startx)

export LANG=zh_TW.UTF-8
export LC_ALL=zh_TW.UTF-8

# invoke global X session script
. /etc/X11/Xsession

在 Linux 上轉入 Unicode 環境時所帶來之挑戰及解決方案

　檔案名稱編碼問題

　　檔案名稱的編碼影響到的將會是我們能否順利在 Linux 下看到正確的檔案名稱。

　　如果是 vfat 的磁碟區，
　　那麼內定就是使用 UTF-8 編碼來儲存檔名。
　　所以只要使用以下方式來掛載 vfat 磁區，就可以無痛將檔案名稱轉換為 UTF-8 編碼了：
　　（請將其寫在 /etc/fstab 裡）

代碼:

/dev/hda5 /FAT32 vfat utf8=1,gid=disk,fmask=113,dmask=002,umask=002 0 0

　　但，如果是 ext2/ext3 之類的磁碟區呢？
　　Linux 所使用的 ext2/ext3 之類的磁碟區，
　　在儲存檔名時是以其原始編碼存入磁碟的，
　　所以我們可能需要某些工具程式來轉換這些檔案名稱，例如 convmv：

代碼:

# 將在 /Path/To/Your/Files 裡的 Big5 編碼檔名轉換成 UTF-8 編碼
# 請用 ./convmv --help 或是 man ./convmv.1.gz 來得到其參數之說明
# 使用 --list 來查看已支援之編碼
# 其中，-f 為原始編碼，-t 為輸出編碼；-r 表是進行遞迴處理
# 以下將會輸出轉換結果，但不會實地進行轉換
./convmv -f big5-eten -t utf8 -r /Path/To/Your/Files

# 實地進行轉換
./convmv -f big5-eten -t utf8 -r --notest /Path/To/Your/Files

　　筆者測試過，它可以成功轉換像是「功蓋許」等特殊檔名，是一個很不錯用的小程式。

　X Terminal

　　我想，能夠完整支援 UTF-8 的 X Terminal 不少。
　　其中，筆者所使用的是 MLTerm。

　　為了能夠加快 MLTerm 的顯示速度，
　　筆者關掉了它的 Anti-Alias 功能，並設定它在處理字串時採用 Unicode 編碼。
　　（請修改 /etc/mlterm/main 或 ~/.mlterm/main）

代碼:

# 在處理字串時，如複製貼上時，將其轉換成 Unicode 編碼。
receive_string_via_ucs=true

# 不使用 Anti-Alias 字型。
use_anti_alias=false

　　設定所使用的 Non-Anti-Alias 之 Unicode 字型：
　　（請修改 /etc/mlterm/font 或 ~/.mlterm/font）

代碼:

ISO8859_1 = -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1;
ISO10646_UCS4_1 = -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1;
ISO10646_UCS4_1_BIWIDTH = -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1;

　　MLTerm 可以支援多國語系、支援 XIM、支援透明背景，
　　也有 GUI 的設定介面，是不可多得的好 X Terminal！

　中文輸入法

　　XCin 在加上一個 Patch 之後，就可以在 zh_TW.UTF-8 下運作了，
　　而幸運的是，這個 Patch 已被 Debian 官方所接受，
　　所以 Debian User 就不必費心去加 Patch 了。
　　但是它必須先於 zh_TW.Big5 下執行，才能將 Locale 轉換為 zh_TW.UTF-8。

　　以 ~/.xinitrc 為例：

代碼:

#!/bin/sh
# $Xorg: xinitrc.cpp,v 1.3 2000/08/17 19:54:30 cpqbld Exp $

# /etc/X11/xinit/xinitrc
#
# global xinitrc file, used by all X sessions started by xinit (startx)

export LC_ALL=zh_TW.Big5
export LANG=zh_TW.Big5

export XMODIFIERS="@im=xcin"
exec /usr/bin/xcin &

export LANG=zh_TW.UTF-8
export LC_ALL=zh_TW.UTF-8

# invoke global X session script
. /etc/X11/Xsession

　　而像是 SCIM 等等輸入法則直接能夠在 zh_TW.UTF-8 環境下運作。
　　如果您有興趣則不妨試試看！

　xlib based 程式：（xedit 等等）

　　只要指定讓 xlib based 程式使用 Unicode 字型，如：unifont，
　　應該就能讓 xlib based 程式在 Unicode 環境下運作。

　　例，在 ~/.Xdefaults 裡頭加入：

代碼:

xedit*international: True
xedit*fontSet: -gnu-unifont-medium-r-normal--16-160-75-75-c-80-iso10646-1

　　就能讓 xedit 支援 Unicode 了。

　Gtk+ based 程式：（XMMS、GIMP 1.2 等等）

　　只要在 /etc/gtk/gtkrc.utf-8 中指定讓 Gtk+ based 程式使用 Unicode 字型，如：

代碼:

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

class "GtkWidget" style "default-text"

　　應該就能讓 xlib 程式在 Unicode 環境下順利運作。

　　但是 XMMS 將也會以 UTF-8 編碼來讀取 ID3 tag，所以反而會在 XMMS 視窗裡出現亂碼。
　　解決方案是把所有的 ID3 tag 轉換成 UTF-8 編碼，或是在播放時顯示檔案名稱。

　QT Based 程式

　　為了能在 QT Based 的程式裡正常顯示 Unicode，
　　建議您安裝支援 Unicode 的字型，如：DFSongSd.ttf，
　　並執行 qt-config，讓 QT Based 程式使用這個 Unicode 字型做為預設的字型。

　　　　注意：DFSongSD.ttf 為 freeware，但是並不是 Free Software。
　　　　　　　請依您喜好來決定是否要下載使用這個字型。

　　否則，在必須顯示多國文字時，常常看到的會是莫名其妙的空白...

　Gtk2+ Based 程式

　　Gtk2+ Based 程式老早就使用 Unicode 做為預設編碼，
　　所以在轉換至 Unicode 環境後更是如魚得水，
　　可以說是完全不會遇到任何問題。
　　我們可以在 ~/.gtkrc-2.0 中指定 Gtk2+ Based 程式的預設字型，例：

代碼:

gtk-font-name = "AR PL Kaitim Big5 14"

　　而 Gtk2+ Based 的程式最可怕的一點是，如果它在該字型中找不到相對應的文字，例：

代碼:

映画ジブリ [ 猫の恩返し ] 主題歌風になる - つじあやの.ogg

　　這串文字，其中的「映」「恩」等字，是可以在文鼎字型裡找到相對應的字；
　　但剩下的「画」「猫」等字就找不到了。
　　但是 Gtk2+ 的函式庫會自動使用其它的字型來把這些字給補滿，
　　所以在 Mozilla 裡還是可以看到完整的字串。真的非常了不起！

　VIM

　　VIM 則內建了方便的自動轉碼功能，
　　方法是在 ~/.vimrc 中加入：

代碼:

" 設定自動轉換為 UTF-8 編碼
set fileencodings=utf-8,big5,euc-jp,gbk,euc-kr,utf-bom,iso8859-1
set encoding=utf8
set tenc=utf8

　　它會自動偵測該文字檔是否為 Big5 / eucJP 等編碼，
　　然後將其轉換為 UTF-8 編碼。
　　但是在存檔時仍會以原有編碼儲存；
　　如果能配合支援 UTF-8 的 X Terminal 那就更加完美了！

Unicode 在samba 上也可實作
在 /etc/samba/smb.conf 中加入：

代碼:

display charset = UTF8
dos charset = UTF8
unix charset = UTF8

然後重新啟動 Samba，
不管 Client 是 MS Windows 95/98/ME/NT/2000/XP/2003 或是 GNU/Linux，
就可以正確得讀取寫入 UTF-8 編碼的檔案名稱了。
您不妨試試看！

　註：MS Windows 95/98/ME 是不支援 UTF-8 的，
　　　所以它們可以正確處理 UTF-8 編碼之中文檔名，
　　　但卻無法處理 Big5 碼以外的檔案名稱。
　　　這是 MS Windows 95/98/ME 先天上的限制，
　　（即使是以 MS Windows NT/2000/2003 為 Server 也會有類似的困擾）
　　　據個人所知，針對這個問題，目前並沒有什麼良好的解決方案。

在 MS Windows 的網路芳鄰中使用 Unicode：

　修改 /etc/samba/smb.conf 如下：

代碼:

display charset = UTF8
dos charset = CP950
unix charset = UTF8

　使用以下參數來掛載 MS Windows Server 之分享目錄：

代碼:

mount -t smbfs -o username=*UserName*,codepage=cp950,iocharset=utf8 //FileServer/共用區 /mnt

　可以在 LinNeighborhood 及 smbclient 所掛載的目錄中使用 Unicode 編碼之檔案名稱及目錄。

使用以下方式掛載 MS Windows 機器所分享的目錄：

代碼:

mount -t cifs -o username=*UserName*,iocharset=utf8 //FileServer/共用區 /mnt

這樣能夠正常存取在 MS Windows 機器上有非 Big5 文字的 Unicode 檔名。

在設定 LinNeighborhood 的 smbmount 之 argument 時，
不用加上 "-o" 這個選項；
而 username 選項也可以省略，
因為這些選項 LinNeighborhood 會自動替您加上去。

例：（我在 LinNeighborhood 裡使用的 smbmount 之 argument）

代碼:

codepage=cp950,iocharset=utf8

的確是可以在 zh_TW.UTF-8 的環境下使用 Unicode 的網路芳鄰。

查看網路的芳鄰：

代碼:

smbclient -U Tetralet%MyPassword -L FileServer

Domain=[MyDomain] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]

Sharename Type Comment
--------- ---- -------
IPC$ IPC 遠端 IPC
D$ Disk 預設共用
共用區 Disk
ADMIN$ Disk 遠端管理
資訊部 Disk
C$ Disk 預設共用

可以正確看到中文字沒問題...

~/.vimrc 的設定

代碼:

set fileencodings=utf-8,big5,gbk,euc-jp,euc-kr,utf-bom,iso8859-1
set encoding=utf8
set tenc=utf8

*在掛載 FAT 分割區時，記得要加上 utf8=1 參數！
*若想在 NTFS 分割區裡正確存取 Unicode 檔案名稱，
請以以下方式來掛載 NTFS 分割區：

代碼:

/dev/hda2 /NTFS ntfs iocharset=utf8,gid=disk,fmask=113,dmask=002,umask=002 0 0

這樣應該就能正確得讀取到 UTF-8 編碼的檔案名稱了。

*在使用gftp的時候中文都不會顯示, 這是gftp的問題嗎
我是暫時把gftp改成用big5顯示 . 修改~/.gftp/gftprc裡 remote_charsets 改成
remote_charsets=big5 中文就可以顯示

MS Windows 系列所提供的 FTP 似乎並不是以 Unicode 編碼的...

我的解決方式是以：

代碼:

LC_ALL=zh_TW.Big5 gftp

來啟動 gftp。

如果對方的ftp站是big5而你這邊是utf8
則無法將檔案下載
所以我將windows下的D用big5 mount就不會有此問題

也就是說修改~/.gftp/gftprc

代碼:

remote_charsets=big5

對方的站必需是big5而你這邊要下載的地方也必需是big5
如果對方是big5而你要下載的地方是utf8則gftp會發生無法下載的問題
所以只要將你存放資料的分割區以big5掛載即可
在linux載轉換成uf8就好了
在gftp尚未解決編碼問題前這或許是一種方法吧

gftprc裡面有說明 ; 用 remote_charsets=big5,utf-8 這樣似乎兩種編碼的中
文檔名都可以顯示也可以抓下來 !

gftp 的編碼修改
而且, 修改這個後, 就可以不用我之前加上的那個非標準的 icnv off 指令, 由 gftp 本身就可以處理 utf-8 (或支援 rfc-2640) 的 server, 加上 remote_charsets 設定, 也可以處理其它指定的編碼.

代碼:

diff -Nur gftp-2.0.18/lib/protocols.c gftp-2.0.18.patched/lib/protocols.c

--- gftp-2.0.18/lib/protocols.c 2005-01-25 10:34:18.000000000 +0800
+++ gftp-2.0.18.patched/lib/protocols.c 2005-02-25 23:07:11.000000000 +0800
@@ -450,11 +450,16 @@
{
ret = g_convert_with_iconv (str, -1, request->iconv, &bread, &bwrite,
&error);
- if (ret == NULL)
- printf (_("Error converting string '%s' from character set %s to character set %s: %sn"),
- str, _(""), "UTF-8", error->message);
-
- return (ret);
+ if (ret == NULL) {
+// printf (_("Error converting string '%s' from character set %s to character set %s: %sn"),
+// str, _(""), "UTF-8", error->message);
+ g_iconv_close (request->iconv);
+ request->iconv = NULL;
+ request->iconv_initialized = 0;
+ }
+ else {
+ return (ret);
+ }
}

gftp_lookup_request_option (request, "remote_charsets", &tempstr);
@@ -521,11 +526,16 @@
{
ret = g_convert_with_iconv (str, -1, request->iconv, &bread, &bwrite,
&error);
- if (ret == NULL)
- printf (_("Error converting string '%s' from character set %s to character set %s: %sn"),
- str, "UTF-8", _(""), error->message);
-
- return (ret);
+ if (ret == NULL) {
+// printf (_("Error converting string '%s' from character set %s to character set %s: %sn"),
+// str, "UTF-8", _(""), error->message);
+ g_iconv_close (request->iconv);
+ request->iconv = NULL;
+ request->iconv_initialized = 0;
+ }
+ else {
+ return (ret);
+ }
}

gftp_lookup_request_option (request, "remote_charsets", &tempstr);

patch 檔案在:
http://www.teatime.com.tw/~tommy/linux/gftp_remote_charsets.patch

給 sarge 用的 deb 在這兒:
http://www.teatime.com.tw/~tommy/debian/gftp_2.0.18-9_all.deb
http://www.teatime.com.tw/~tommy/debian/gftp-gtk_2.0.18-9_i386.deb
http://www.teatime.com.tw/~tommy/debian/gftp-common_2.0.18-9_i386.deb
http://www.teatime.com.tw/~tommy/debian/gftp-text_2.0.18-9_i386.deb

由於 gftp 內部在處理資料時, 似乎都轉成 utf-8 處理, 但是程式中這部份的邏輯似乎有點怪怪的, 除了在 remote_charsets 有設定時, 會把所有送出給 remote 的資料由 utf-8 再轉成所設定的編碼, 也會把由 remote 收到的資料由 remote_charsets 所設定的編碼轉成 utf-8 外, 對於 local (還有其他非 ftp 協定?), 也一直呼叫相同的函式來處理. (看不出有什麼判斷來決定那些要轉, 那些不用轉, 所以... 有些不該轉的也轉了... 有些該轉的, 又做了兩次轉換, 又轉回去原本的編碼)

原本打算把 gftp 修改成符合 rfc-2640.
1. 連線時送出 FEAT 指令, 判斷對方是否支援 rfc-2640. 也就是有 UTF8 feature.
2. 如果對於有支援 rfc-2640, 則不要使用 remote_charsets 的設定來轉碼. 應直接使用 utf-8.
3. 所有 local 端的檔名, 再由 utf-8 <-> local 之間互轉.

不過... 有些邏輯看了一上午, 實在看不太出來. 所以決定就用最簡單的改法. 就是假定 local 端一律使用 utf-8, 檔案儲存的時候, 如果檔名非 utf-8 就轉成 utf-8.

這個改法並非每個人都適用, 如果你的 locale 並沒設定為 utf-8, 應該會有問題.

至少, 這個改法, 符合我目前本身使用的需求. 可以正常看到中文檔名, 傳檔回來也是正常的 utf-8 中文檔名.

1. 如果 ftp server 使用 utf-8, 則不管 gftp 使用 big5 或 utf-8 都可以正常看到中文.
2. 如果 ftp server 使用 big5, 則在 remote_charsets 中有設定 big5 的話, 也可以正常看到中文.
3. 在指令的部份, dir 或 get 都可以輸入中文字當參數.
4. 不管 gftp 在什麼環境下執行, big5 or utf-8 or 其它, 所有 local 端的檔名, 都會使用 utf-8 處理.

也就是說, 如果你不是在 utf-8 的環境下頭的話, 最好不要用這個版本. 以免在 local 找不到 big5 的中文檔名, 抓回來的中文檔名也變成 utf-8 編碼.

我試過 gftp-text/gftp-gtk 兩個版本, 都可以正常使用. 只是有些傳送的訊息, 可能會出現 big5 碼, 會有轉碼失敗的錯誤訊息, 應該不會影響正常使用.

修改一下 vsftpd, 以符合 rfc-2640 的需求
新的 patch 可以到這兒抓
http://www.teatime.com.tw/~tommy/linux/vsftpd_iconv.patch

如果是使用 Debian Sarge, 也可以直接用這個:
http://www.teatime.com.tw/~tommy/debian/vsftpd_2.0.1-11_i386.deb

同之前的設定, 在把 enable_iconv 設為 yes, 且 remote_charset 設為 UTF-8 的時候, 會在 Clinet 使用 FEAT 指令時, 傳回 UTF8 表示支援檔名使用 UTF-8 編碼. (rfc-2640 好像就是要求 FEAT 有 UTF8, 且檔名都用 UTF-8 傳送)

另外, 我也改了一份 FileZilla 2.2.11 支援 rfc-2640 的版本. 麻煩測試一下.
http://www.teatime.com.tw/~tommy/FileZilla.zip

這個版本的 FileZilla 比較小, 因為沒支援 libidn.a (我還找不到 win32 的版本), 所以... domain name 不能用非英文的名字.
製造時, 我的 Visual Studio 2003 說無法載入 FzSFtp 的那個 project, 不過似乎還是可以使用 sftp.

與原本的版本差異除了上述 libidn.a 外, 就是在一開始連線時, 在送出 FEAT 指令後, 如果對方有回 UTF8, 在這之後, 就一律使用 UTF-8 來傳送檔名. 程式會將收到的檔名, 由 UTF-8 轉成 Windows 的 Unicode, 再轉成 ANSI CodePage (在繁體中文下就是 CP950), 在送出指令時, 會由 Windows 的 ANSI CodePage 轉成 Unicode 再轉成 UTF-8, 然後送出.
當然, 如果對方不支援 rfc-2640 的話, 也就應該不會有 UTF8 出現在 FEAT 中, 就不會做任何的轉換.

使用 dpkg-reconfigure locales 來重建 Locales 檔案
在zh_TW.UTF-8環境下才會將gtk+的配置檔設成gtkrc.zh_TW.utf-8
代碼:
$ locale -a
C
en_US
en_US.iso88591
en_US.utf8
ja_JP.utf8
POSIX
zh_CN.gb18030
zh_CN.utf8
zh_TW
zh_TW.big5
zh_TW.utf8
$ locale
LANG=zh_TW.UTF-8
LC_CTYPE="zh_TW.UTF-8"
LC_NUMERIC="zh_TW.UTF-8"
LC_TIME="zh_TW.UTF-8"
LC_COLLATE="zh_TW.UTF-8"
LC_MONETARY="zh_TW.UTF-8"
LC_MESSAGES="zh_TW.UTF-8"
LC_PAPER="zh_TW.UTF-8"
LC_NAME="zh_TW.UTF-8"
LC_ADDRESS="zh_TW.UTF-8"
LC_TELEPHONE="zh_TW.UTF-8"
LC_MEASUREMENT="zh_TW.UTF-8"
LC_IDENTIFICATION="zh_TW.UTF-8"
LC_ALL=zh_TW.UTF-8

.gtkrc
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"

xmms字型問題
試著修改 ~/.xmms/config 如下：

代碼:

playlist_font=-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
mainwin_font=-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

修改 gtkrc.zh_TW.utf-8 或 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"

因為在 ja_JA.UTF-8 的環境下，似乎抓不到 unifont 的英文字

手動安裝
apt-get
2.1 deb ftp://debian.linux.org.tw/pub/apt/ unstable main
2.2 deb http://www.csdc.twbbs.org/~joseph/ubuntu hoary universe

gtk+(1.2)總是要認出它來，找到字，xmms才能顯示。

現在網路上找到的手動安裝法，都是告訴你丟進去然後fc-cache -f -v就好。可是這種安裝法gtk+找不到。不信，你可以進xmms的字型選擇找有沒有ar pl new sung。

而使用apt-get 裝上的話，有兩種來源，2.1叫ttf-fieflysung，2.2叫ttf-arphic-newsung。它們的字型名稱及位置也不同，2.1在 /usr/share/fonts/truetype/fireflysung.ttf，2.2在 /usr/share/fonts/truetype/arphic/newsung.ttf。

2.1裝上的新宋體，gtk+認得到也找得到。2.2裝上的新宋體，gtk+認得到，但"找不到"！（可選擇，但選了會顯示"not avaliable"）

裝2.2的方式是它會自動對你中文桌面字型做最佳化。2.1不會。也許是因為2.2有關於Ubuntu的設定的關係吧！所以它沒設好讓gtk+ 1.2認得的設定，不知道是不是因為它在defoma的設定檔(/etc/defoma/hints/)設定的路徑也是錯誤的關係。至少我將它設定後讓 defoma和fc-cache再抓一次，gtk+還是找不到。

解決方式：
1.手動新增後，讓gtk+1.2和gtk+2都能找得到和顯示。（我不會）
2.1裝上後，對gtk+1.2繁中字型最佳化：
編輯/etc/gtk/gtkrc.zh_TW.utf-8：

代碼:

style "gtk-default-zh-tw" {
fontset = "-adobe-helvetica-medium-r-normal-*-14-*-*-*-p-*-iso8859-1,
-arphic-ar pl new sung-medium-r-normal-*-15-*-*-*-m-*-big5-0"}
class "GtkWidget" style "gtk-default-zh-tw"

對gtk+2.0中文字型最佳化：
編輯/etc/fonts/local.conf或是~/.fonts.conf，加上1.喜好順序：

代碼:

serif

Bitstream Vera Serif
AR PL New Sung
Times
Times New Roman
Nimbus Roman No9 L
Luxi Serif
Kochi Mincho
AR PL SungtiL GB
AR PL Mingti2L Big5
Baekmuk Batang
FreeSerif

sans-serif

Bitstream Vera Sans
AR PL New Sung
Helvetica
Arial
Verdana
Nimbus Sans L
Luxi Sans
Kochi Gothic
AR PL KaitiM GB
AR PL KaitiM Big5
Baekmuk Dotum
SimSun
FreeSans

monospace

Andale Mono
Bitstream Vera Sans Mono
AR PL New Sung
Courier
Courier New
Luxi Mono
Nimbus Mono L
NSimSun
FreeMono

2.字型美化：

代碼: