Re: CSS transform 中文字變形問題 — 拿掉點陣字形（Bitmap Strike）的 CSS3 Fonts 屬性

(11/07/06 5:30), Yuan Chao wrote:
>> 所以 Linux 下 FF 的現況是：
>> 1) 沒斜體的時候使用點陣字形，並且關閉 AA
>> 2) 斜體的時候仍使用點陣字形，但是開啟 AA
> 不對，
> 1) 沒斜體的時候，依照使用者fontconfig的設定，
> 「通常」有內嵌點陣時優先用點陣字，關閉AA。

好羨慕，我在 Mac 上到目前為止還沒辦法重現這個部份 xddd
我是這樣實驗的，我把「文鼎 PL 新宋」[1]的有內嵌點陣的字形的那個，用
FontForge 做了一個只有向量字形跟一個只有點陣字形的 tff。然後，原先那個
（有內嵌字形的那個）跟只有向量字形的那個不管用什麼大小試，或是用
-webkit-font-smoothing 調 AA 都看起來一樣。只有點陣字形的那個則是一片空
白，這好像是 Mac 對只有點陣字形的 tff 要求比較多[2]

有人知道在什麼樣的條件下 Mac 才會用內嵌點陣字形嗎？明天試試 Windows......

[1] http://cle.linux.org.tw/fonts/FireFly/
[2] http://fontforge.sourceforge.net/bitmaponlysfnt.html


> 2) artificial 斜體的時候，無視內嵌點陣字一律用向量字，並開啟AA。
>  (多數distro預設的 fontconfig 規則)

喔喔，看起來 Linux 很可以試...... 目前 rotate 是點陣字 rotate 然後不開啟
AA 嗎？

> 請參考附檔的截圖font_test.png。當然，這裡是對LCD螢幕最佳化。
>
> 對比上Google Chrome 13.0.782.32 beta的截圖ft_chrome.png，似乎google仍需努力... XD
> 不僅AA朦朧(也許不少人反而喜歡？)，點陣字沒有辦法顯示斜體。

第一次拜見點陣字無法顯示斜體的情形～

> 也許該辦個投票？你喜歡哪個？(我想要3，但chrome只給我2)
> 1) http://labs.trolltech.com/blogs/wp-content/uploads/2008/09/text_nofilter_slight1.png
> 2) http://labs.trolltech.com/blogs/wp-content/uploads/2008/09/text_filter_slight2.png
> 3) http://labs.trolltech.com/blogs/wp-content/uploads/2008/09/text_legacy1.png
> 4) http://labs.trolltech.com/blogs/wp-content/uploads/2008/09/text_legacy_slight1.png
>
> (參考 http://labs.qt.nokia.com/2008/09/01/subpixel-antialiasing-on-x11/
> http://martin.ankerl.com/2009/01/22/beautiful-font-hinting-in-ubuntu-810/ 說明)

沒有那個可以看一行就判斷好壞的眼力 orz

>>> 所以這裡我們應該做的，是去FF發bug report改善transform後字型顯示的品質？
>> 就原先火狐的頁面的問題的確是這樣，雖然連 ABCD 都有問題代表這不是中文的問
>> 題也可能有人發過這個 bug report 了。也就像你講的，那跟 AA 比較有關，跟點
>> 陣字型應該比較無關。
> 要看這個ABCD是中文字型，還是英文字型來的！(通常使用者無法分別指定不同字型)
> 中文字型的英數字會以中文同樣方式處理。

我那時候是設 font-family: Arial，我想那應該還是 AA 的問題。

>>> 個人覺得這裡有點倒因為果，因為點陣字型開AA是沒有意義的... XD
> 補充一點，「古代」的Linux只有點陣字(X core font)，縮放點陣字才需要開AA。
> 當然效果通常慘不忍睹，只比全鋸齒好一點點。
>
>>> 而且如果使用明體字型的話，小字號使用向量開啟AA不會比較好看，
>> 那需要做的實驗好像是，在明體，小字號，有 transform 的情形，比較以下哪個
>> 比較好看：
>> 1) 點陣字型，不開 AA
>> 2) 點陣字型，開 AA
>> 3) 向量字型，不開 AA
>> 4) 向量字型，開 AA
> 個人覺得應該採用4)，與斜體同樣的處理方式。而2)應該是不需要的。
>
>> 2 會遠勝 1 嗎？另外，4 會跟 2 差很多嗎（需要了解 font-bitmap: none; 之類
>> 在一般電腦上到底價值有多高）？
>>
>> 我可以想像在沒有 AA 的環境（電子書？），3 應該會遠勝於 1 所以 font-
>> bitmap 可能有價值，不過如果 Hax 能提供一張照片佐證那就最好了。
> 個人經驗，hinting做得好的話，3也許可以接近1，但通常應該手工刻的1會比算出來的3好。

你確定嗎？我這邊是要問有 transform 的情形，因為這是 Hax 要拿掉點陣字形的
主因。

>> 全部歸結到 UA 的 implementation 的好處的是不錯，畢竟不用加太難懂的新屬
>> 性。唯一個缺點是在動態環境下不知道會不會產生不協調的奇怪現象。比如說你想
>> 像一下一串字在那裡慢慢旋轉但是只有 在 0 度的時候沒有 AA。
> 應該是0, 90, 180, 270度的時候... :D

哈哈 :D 不過這邊重點應該是 0 度可能不算有 transformation 的這個奇異點。
如果照你之前建議的有 transformation 的才開 AA 那「完全沒轉」跟「轉 0.001
度」 會差很多，當然這樣可能是最簡單的設計吧，就像你後面講的。

>> 雖然這種情形應該很少發生可以暫時無視、、、
> 也許比較簡單的作法，是只要有transformation，就一律用向量字？
> 畢竟在網頁特效上，歪斜的小字講求 readability 似乎不是很有意義。 :D

這樣是簡單，不過實作上可能要注意的就是動畫經過剛好不旋轉的那個地方的時候
不要突然用點陣字吧。但是動畫的開頭或是結尾是「不動」的時候會不會 震一
下？所以我之前才有的第四個提案是 rotate(0) 代表「這個地方將來或是曾經是
歪斜的，不需要注意 readibiliy 所以不需要用內嵌點陣字形」

我還是好想在我的電腦上看到內嵌點陣字形被使用的情形啊 XDD

> 另外一個問題，不曉得目前幾個瀏覽器對文字transform的實作法是怎樣的？
> 因為sub-pixel AA必須考慮到LCD的RGB排列方向，如果是先render完成點陣圖，
> 再transform的話，文字sub-pixel AA也會爛掉的。

不知道耶，我也很好奇。照你講的話應該是先 transform 再 render 吧。canvas
的情況不知道怎樣？

對了，我開了一個「內嵌點陣字形與光柵化」[3]的 wiki 頁面，歡迎提供專業知識。

[3]
http://www.w3.org/html/ig/zh/wiki/%E5%85%A7%E5%B5%8C%E5%AD%97%E9%AB%94%E8%88%87%E5%85%89%E6%9F%B5%E5%8C%96

Kenny

Received on Wednesday, 6 July 2011 21:53:01 UTC