關於螢火飛大姐的 xttfm.ttfm

[octapult]

不知道各位網友有沒有看過螢火飛大姐的 "中文字型完全解決方案 "？她的解決方法可以解決中文字型裡面有關英文字距過寬的問題。剛剛弟將她提供的 xttfm.ttfm 下載回來研究，發現她是將 fontproperties 由 m 改為 p，例如-dynalab-pmingliu-medium-r-normal--0-0-0-0-m-0-big5-0 變為 -dynalab-pmingliu-medium-r-normal--0-0-0-0-p-0-big5-0 。

阿信兄如果不健忘的話，應該記得以前我們以前有討論過 hints 檔案裡面的 Width 參數吧？當 Width = Variable 的時候，設定出來的字型就跟螢火飛大姐的設定一樣，的確可以解決英文字距過寬的問題，可是那時候卻出現新的問題，就是 mozilla 在瀏覽某些網頁的時候很容易讓整個 X 掛掉。不知道螢火飛大姐那邊有沒有遇過相同的問題？如果阿信兄或是其他網友有使用螢火飛大姐的 xttfm.ttfm，能不能請您分享一下使用過程有沒有任何問題，弟想要確定 Debian 和 RedHat 的情況是否有所不同。

謝謝

[maujalen]

嗯嗯~~手邊有一本書有提到字型的觀念....

-fndry-fmly-wght-slant-sWdth-adstyl-pxlsz-ptSz-resx-resy-spc-avgWdth-rgstry-encdng

fndry FOUNDRY 廠商名稱
fmly Family 字型名稱
wght Weight 字體是否粗體表示
--- medium(正常) , bold(粗體)
slant Slant 字體是否斜體表示
--- r Roman 字體 , 文字正常顯示
--- i Italic 字體 , 文字斜體表示
--- o oblique 字體 , 斜體字
sWdth Set Width 文字水平寬度
--- normal 標準寬度
--- Narrow 窄體字
adstyl Additional Style 額外的類別 (通常不指定)
pxlsz Pixel Size 字體大小
ptSz Point Size 組成文字的顆粒大小
resx-resy Horizontal-Vertical Resolution 垂直/水平 解析度
--- 組成字體的顆粒水平/垂直 解析度 , 或稱密度(dpi)
spc Spacing 字體的間距
--- p , proportional , 字距隨字母的不同而改變
--- m , mono 字距保持固定
--- c , (前幾個借書的人沒有好好保護好書...所以這行不見了~~~~:cring:)
avgWdth Average Width 字體的平均寬度
rgstry Character Set 字集 ex: Iso-8859 , big5
encdng Encoding 編碼方式

睡不著打點字看看會不會比較好睡~~~~~~~

[octapult]

小弟之所以突然想要解決這個問題，是因為 mingliu 在 unstable 裡面的 qt3 3.0.5-4 之下，不管有沒有開啟 anti-aliasing，整個字體都是破碎的，而且英文字距過大 gtk 底下只有 mozilla 開啟 anti-aliasing 的時候，mingliu 才是破碎的，不過在 gtk 沒有英文字距過寬的問題。

弟昨天小試了一下，總共試了兩種方式：第一種是 Width = Variable，會將這個字型的 spacing 全部設為 "-p-"；第二種是 "X-Spacing = c p"，會將這個字型的 spacing 設為 "-c-" 和 "-p-" 兩種。

兩種設定方式都會造成進入 KDE 的時間大幅增加，而且在開啟 control center 的時候、或是想要設定字型的時候，都會像當機一樣的停上 5~10 秒；在 GNOME 底下開啟控制台、或是想要選字型的時候，也是一樣會有上述停止 5~10 秒的情形。

真是糟糕

[maujalen]

這.....呵呵.....小的沒沒有灌GNOME和KDE所以不知道那樣的狀況......想當然爾....我幫不上忙~~~
而我不觀那兩個的原因是因為那讓我感覺不如去用Windows XP
我的電腦配備並不算是很好....
所以我並不希望作業系統在一般作業環境時就浪費掉太多系統資源
這讓我覺得我要用的軟體的速度變慢了....(純個人觀感)
所以我不使用KDE GNOME那兩個....雖然看起來漂亮多了....
我灌的是Window Maker 和 BlackBOX
這讓我感覺我作正經事的時候效率比較好.....



至於打混摸魚上網打逼跟人說安安....不在此限(浪費時間咩 )

[阿威]

octapult大
妳的xwindow是哪一個版阿
是4.2.1嗎

[octapult]

octapult大
妳的xwindow是哪一個版阿
是4.2.1嗎

是的，我使用 x-window-system 4.2.1。
剛剛螢火飛大姐已經提供她的 fonts.dir 供我參考，經由她的資料，
才知道原來 mingliu 有提供這麼多的 encoding，其中還包括日文哦：
http://linuxfab.com/indexForumData.php? ... D=5#7682-5

我現在正在想辦法修改 mingliu 的 hints 檔，看看能不能產生同樣的 fonts.dir 出來，
也看看能不能改正字體支離破碎的情況。
(目前我這邊的情況是，qt3 底下不管有沒有開 anti-aliasing，字體都是破碎的。
mozilla 底下如果開啟 anti-aliasing，字體也是破碎的。)

[octapult]

令人驚訝! 我以手動的方式將螢火飛大姐的 fonts.dir 加進自己的 X 裡 (不經由 Defoma)，結果細明體在 qt3 底下不再破碎。雖然也不能開啟 AA，不過至少字體不再破碎、英文字距不再過寬，就已經很足夠了。

可惜的是，我研究不出經由修改 Defoma hints 的方式來達到相同的效果
現在只好先暫時維持手動增加細明體的方式了。

[阿信]

octapult兄加油找出最好的hint檔案來造福大家。

[octapult]

目前的 Defoma 似乎不能針對不同的 charset 給予不同的 spacing 的設定方式，也就是似乎不能經由編寫 hints 來達到上述的目的...另外也不支援 embeded bitmap...要達成這個功能，可能需要改寫 Defoma 的一些程式...

另外剛剛才發現，只要 XftConfig 裡面有加入細明體的路徑，不管有沒有開啟 AA，字體都是支離破碎的、英文字距過寬。原來字體支離破碎、英文字距過寬，跟原本的 Defoma hints 可能沒有關係，而是跟 Xft 和 freetype2 有關係，讓我突然有做白工的感覺...

[高原之狼]

另外剛剛才發現，只要 XftConfig 裡面有加入細明體的路徑，不管有沒有開啟 AA，字體都是支離破碎的、英文字距過寬。原來字體支離破碎、英文字距過寬，跟原本的 Defoma hints 可能沒有關係，而是跟 Xft 和 freetype2 有關係，讓我突然有做白工的感覺... :-(

Thanks octapult for these research.

I think you are right, defoma and freetype2 do not support Asian TrueType fonts very well now. I noticed that xttfm.ttfm uses xtt module, and xtt should deal with Asian fonts much better than freetype. (If I remember correctly xtt is written by Japanese.)

The following link maybe helpful:
http://www.freetype.org/pipermail/devel ... 04236.html

[octapult]

高原之狼兄，多謝您提供的訊息

如果大家使用 Defoma 來安裝細明體，希望能在 KDE 底下開啟 AA，但是又不希望細明體被破壞的話，可以在 /etc/X11/XftConfig 或是 ~/.xftconfig 加入下面這兩行：

代碼: 選擇全部

match any family == "mingliu edit render = false;
match any family == "pmingliu edit render = false;


加入上面這兩行後，Xft 就不會去處理 mingliu 和 pmingliu 了，字體也就不再支離破碎。不過 pmingliu 卻有英文字體擠在一起的情況

[阿信]

match any family == "mingliu" edit render = false;
match any family == "pmingliu" edit render = false;

少加了"

[octapult]

昨天又遇到一個必須勤看 Debian Weekly News 的好理由。原來 DWN 2002/10/22 早就提到由於 Apple 宣稱他們擁有某個專利，所以 libfreetype6 自從 2.1.2-8 起，就已經將 bytecode interpreter 給關閉。而這個選項被關閉，就是造成細明體在開啟 AA 以後會支離破碎的原因。不過 libfreetype6 的維護者 Anthony Fok 已經在 unstable 裡面的 2.1.2-10，又將 bytecode interpreter 打開了。所以想要開啟 AA 的網友可以自己重新編譯 libfreetype6，或者是直接升級為 unstable 的版本。不過如果您想要直接升級 unstable 裡的 libfreetype 2.1.2-10 的話要注意一下，由於它會順便升級 libc6，所以有些您自己編譯的軟體可能需要重新編譯以後才能執行。

雖然在升級了 libfreetype6 之後，終於可以在 KDE 順利開啟 AA，可是在 Konqueror 底下卻會出現英文字距變成雙倍的情形，所以 /etc/X11/XftConfig 或是 ~/.xftconfig 必須做些修改才行：

代碼: 選擇全部

# 底下為我在 Konqueror 會使用到的中/英文字型
# 必須將 spacing �]為 proportional 才能正常顯示英文：

match any family == "mingliu" edit spacing = proportional;
match any family == "pmingliu" edit spacing = proportional;
match any family == "times new roman" edit spacing = proportional;
match any family == "georgia" edit spacing = proportional;
match any family == "verdana" edit spacing = proportional;
match any family == "trebuchet.ms" edit spacing = proportional;
match any family == "comic.sans.ms" edit spacing = proportional;
match any family == "arial" edit spacing = proportional;

# 由於我使用細明體最主要的原�]是在它內嵌的 bitmap 字型，
# 所以我將 point size 9、11、12 的 render 取消，
# 這樣在這些 point size 的時候就會顯示 bitmap 字型了。

match
 any family == "mingliu"
 any size == 9
edit
 render = false;

match
 any family == "mingliu"
 any size == 11
edit
 render = false;

match
 any family == "mingliu"
 any size == 12
edit
 render = false;


最後是使用 qtconfig 裡面的 "字型替換" 功能，增加了 mingliu 替換 times new roman、georgia、verdana、trebuchet ms、comic sans ms 和 arial 等字型。這樣一來，qt 在使用前面這些英文字型、如果遇到 big5 編碼的時候，會自動以 mingliu 取代，就不會像以前一樣用文鼎楷體做替換了。底下有幾張抓圖供大家參考：

mozilla 1.1 底下，新細明體 (AA) 與新細明體 (no AA) 共存：
http://home.kimo.com.tw/octapult/mozilla-aa-tw.html

Konqueror 瀏覽英文網頁：
http://home.kimo.com.tw/octapult/konqueror-aa-en.html

Konqueror 瀏覽中文網頁：
http://home.kimo.com.tw/octapult/konqueror-aa-tw.html

測試環境： Debian testing/unstable、KDE 3.0.4
mingliu/pmingliu 安裝方式仍然採用 "Debian 無痛起步法" 裡面的設定

[阿信]

天阿，真是漂亮，看來mingliu在9,11,12的non-anti-aliasing比較漂亮窩。

雖然我都沒有使用anti-aliasing，但最近會發現到mozilla在使用大字體的時候，

會有名顯得鋸齒狀，用anti-aliasing可能會比較好看，等一下來換好了，

但怕mozilla會變慢...

[octapult]

mozilla 不會變慢，只是開啟了 AA 以後，就不能使用斜體和粗體了。不過文鼎明/楷體也是有同樣的問題。