制作网页过程中，有时使用了大量的自定义字体。这些字体在不同浏览器中渲染的效果不一致，有时偏粗，有时偏细。这种情况如何避免？
如果font-famaily属性只写自定义的字体，当文字出现时候可能字体还没加载完毕，这会文字不会出现。那么字体如何进行预加载？
font-famaily
字体转换的时候，原始字体的格式是否有区别，是用OTF还是TTF？
人生最曼妙的风景，竟是内心的淡定与从容！
2/15更新：做了一番調查，對字體渲染結果的控製給出一些初步的方案。
關於字體顯示，必須接受的一點事實是：它完全取決於用戶操作係統和瀏覽器實現的上下文，大多終端上都僅僅對用戶開放控製字體的渲染的開關，而缺乏相應的控製接口或CSS屬性。
這裏有一個字體渲染實測結果截圖展示。造成渲染區別的主要是以下幾點（wiki: Font rasterization）：
相對應的控製有：
-webkit-font-smoothing: antialiased;
Gabriela-Light
Gabriela-Regular
此外：
-webkit-text-stroke
接口不健全，各個終端表現不一，這基本就是現狀了。Mockee的關於字體渲染的ppt裏說到：“接受現實，假設最壞的情況，等待未來新標準、新實現。”
如果LZ說的是@font-face的話。這個問題確實是存在的，如何解決呢？
沙渺在這裏探索了一下字體預加載的方案，裏麵遇到的困難已經闡述得很詳盡了。
目前為止，比較靠譜的方式是：使用webfont loader，在字體加載成功的回調函數中再應用相應的font-family的CSS樣式。
我剛才谘詢設計師，他說，“可能有些非常細微的參數不對等吧”…… = =
= =
這種問題可能做字體搞排印的才會明白。這方麵的問題建議提到知乎上，然後@梁海或者其他這方麵的人。
下麵的內容是font-face的fallback問題的一個複現方式，給那些沒有見到過這個現象的人……
用chrome看看這個DEMO吧：
http://jsfiddle.net/humphry/d86WC/
在這裏我使用Fiddler將對woff的請求後的response捕獲，捕獲之後，由於對於瀏覽器來說，這個請求一直沒有返回，我們可以看看此時的結果：
將捕獲的response返回，得到這個結果：
可以看到，在.sample { font-family: 'Gabriela', serif; }中我們設置的serif的fallback沒有在加載過程中出現。
.sample { font-family: 'Gabriela', serif; }
因此，@font-face加載成功之前的字體空白顯示問題確實存在，瀏覽器沒有按照我們想象的，在@font-face加載成功之前使用fallback字體，在@font-face加載成功之後換用@font-face定義的字體，起碼chrome不是這樣。
使用@font-face吧。你先用工具導出.ttf格式，然後使用字體轉換工具，轉換成好幾種格式（為了各種瀏覽器的支持），再用吧。 詳情點擊：http://www.w3cplus.com/content/css3-font-face
問題一：我用的時候沒有這種感覺，你是不是沒有加載其他格式導致瀏覽器無法識別字體引起的。參考下麵問題三的回答。http://www.smashingmagazine.com/2011/03/02/the-font-face-rule-revisited-and-useful-tricks/ 比較完善的介紹字體格式的文章
問題二：沒加載完是會使用瀏覽器支持的默認字體，字體加載完才顯示自定義的 問題三：http://caniuse.com/#feat=fontface 這是@font-face的支持情況，下麵“Sub-features”可以看各個font格式的支持情況，所以為了保證兼容性：
@font-face { font-family: 'MyWebFont'; src: url('webfont.eot'); /* IE9 Compat Modes */ src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */ url('webfont.woff') format('woff'), /* Modern Browsers */ url('webfont.ttf') format('truetype'), /* Safari, Android, iOS */ url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */ font-weight: normal; font-style: normal; }
http://www.fontsquirrel.com/tools/webfont-generator 我一般是用這個來導出各個格式，它也有在線的字體選擇
2/15更新：做了一番調查，對字體渲染結果的控製給出一些初步的方案。
關於字體渲染效果不一致
關於字體顯示，必須接受的一點事實是：它完全取決於用戶操作係統和瀏覽器實現的上下文，大多終端上都僅僅對用戶開放控製字體的渲染的開關，而缺乏相應的控製接口或CSS屬性。
這裏有一個字體渲染實測結果截圖展示。造成渲染區別的主要是以下幾點（wiki: Font rasterization）：
相對應的控製有：
-webkit-font-smoothing: antialiased;，可以將chrome瀏覽器的字體渲染調為灰度渲染。在The New Yorker、Path等網站中，均使用了這個方案，它可以使webkit內核的瀏覽器字重表現一致。（使用了次像素平滑之後，字重普遍比灰度渲染之後的字體重，效果詳見攜程的這個DEMO）。Gabriela-Light和Gabriela-Regular此外：
-webkit-text-stroke的hack解決問題，詳參How to fix the ugly font rendering in Google Chrome接口不健全，各個終端表現不一，這基本就是現狀了。Mockee的關於字體渲染的ppt裏說到：“接受現實，假設最壞的情況，等待未來新標準、新實現。”
關於@font-face加載成功之前的字體空白顯示問題
如果LZ說的是@font-face的話。這個問題確實是存在的，如何解決呢？
沙渺在這裏探索了一下字體預加載的方案，裏麵遇到的困難已經闡述得很詳盡了。
目前為止，比較靠譜的方式是：使用webfont loader，在字體加載成功的回調函數中再應用相應的font-family的CSS樣式。
字體轉換的原始字體的相應區別
我剛才谘詢設計師，他說，“可能有些非常細微的參數不對等吧”……
= =這種問題可能做字體搞排印的才會明白。這方麵的問題建議提到知乎上，然後@梁海或者其他這方麵的人。
下麵的內容是font-face的fallback問題的一個複現方式，給那些沒有見到過這個現象的人……
用chrome看看這個DEMO吧：
http://jsfiddle.net/humphry/d86WC/
在這裏我使用Fiddler將對woff的請求後的response捕獲，捕獲之後，由於對於瀏覽器來說，這個請求一直沒有返回，我們可以看看此時的結果：
將捕獲的response返回，得到這個結果：
可以看到，在
.sample { font-family: 'Gabriela', serif; }中我們設置的serif的fallback沒有在加載過程中出現。因此，@font-face加載成功之前的字體空白顯示問題確實存在，瀏覽器沒有按照我們想象的，在@font-face加載成功之前使用fallback字體，在@font-face加載成功之後換用@font-face定義的字體，起碼chrome不是這樣。
使用@font-face吧。你先用工具導出.ttf格式，然後使用字體轉換工具，轉換成好幾種格式（為了各種瀏覽器的支持），再用吧。
詳情點擊：http://www.w3cplus.com/content/css3-font-face
問題一：我用的時候沒有這種感覺，你是不是沒有加載其他格式導致瀏覽器無法識別字體引起的。參考下麵問題三的回答。
http://www.smashingmagazine.com/2011/03/02/the-font-face-rule-revisited-and-useful-tricks/ 比較完善的介紹字體格式的文章
問題二：沒加載完是會使用瀏覽器支持的默認字體，字體加載完才顯示自定義的
問題三：
http://caniuse.com/#feat=fontface
這是@font-face的支持情況，下麵“Sub-features”可以看各個font格式的支持情況，所以為了保證兼容性：
http://www.fontsquirrel.com/tools/webfont-generator
我一般是用這個來導出各個格式，它也有在線的字體選擇