Wednesday, December 14, 2011
LHC實驗發表2011年尋找Higgs粒子的成果
關於這篇報導：
http://chinese.engadget.com/2011/12/13/cern-dont-believe-the-higgs-boson-hype/1#c35142024
希格斯玻色子找到了嗎？還差一點
應該是質量的來源，關於重力的影響，由於在小尺度下真的太弱了，高能物理實驗中多是忽略不計的。重力子(graviton)目前也是僅只於理論模型。由於115-130 GeV這個能量(質量)區間，可以說是實驗上最困難的：相對容易的四輕子衰變模式，質量得在180 GeV左右以上。(約是兩個Z玻色子的質量)而雙光子的偵測，除了量能器的精確度比不上帶電輕子的軌跡，背景也因為高能量下很容易被pi0誤導。所以兩個實驗目前看到的事例，在統計上的顯著性差異 (significance) 不夠 (目前2.x-3.x個標準差，未達到"發現"所需的5個標準差的"業界慣例")，所以都只給了95%「信心水準」的排除區間。
這裡是研討會的簡報檔以及錄影：
http://indico.cern.ch/conferenceDisplay.py?confId=164890
CMS實驗的官方消息發布，以及相關資料：
http://cms.web.cern.ch/news/cms-search-standard-model-higgs-boson-lhc-data-2010-and-2011
Atlas官方新聞發布：
https://twiki.cern.ch/twiki/bin/view/AtlasPublic/AtlasResultsHiggsDec11
(利益揭露：個人是參與CMS實驗的member之一。)
Sunday, August 21, 2011
別再碎了... 細明體！
COSCUP的閦電秀簡報。
別再碎了 ... 細明體從使用者的角度看 OSS 字型描繪問題
別再碎了 ... 細明體從使用者的角度看 OSS 字型描繪問題
No more fractures MingLiu font!
View more presentations from Yuan CHAO
Tuesday, April 12, 2011
關於細明體與標楷體顯示破碎的問題 (續)
陸陸續續又有新的技術加入FreeType，讓中日韓文的漢字也能夠在理想的速度下，享有autohint與autofit帶來的好處。
Jserv's blog February 05, 2006
FreeType 新進展
http://blog.linux.org.tw/~jserv/archives/001489.html
Kanru's Adventure Journal/ archives/
Freetype 2.2rc3 + new Clearlooks
Mon 27 Feb 2006 01:29:02 AM CST
Freetype 2.2rc3，包含 olv 整合的 CJK autofit patch，對於中文字可以 render 的美美的 :)
http://kanru.info/blog/archives/211/
所以王子與公主從就過著幸福快樂的生活了嗎？其實不然。
微軟視窗內附的字型：細明體與標楷體可說是目前流通最大的字型。這兩個字型是由華康科技(日商收購後更名為威鋒數位)所製作，採用了筆劃組字的技術，進一步縮小的儲存空間，也內嵌了點陣字型對小字型做了最佳化。這裡筆劃組字的技術，就是借用bytecode的指令，把筆劃大小與位置的修正，提供給字型描繪器(render)。
就在這裡問題來了，把筆劃放到正確的位置與大小，需要BCI的支援。而大多數的情況，Linux 與其他使用 FreeType 的發行商，為了避免被專利所有權人收取權利金，都在編譯 FreeType 的時候，把 BCI 的支援關閉，改用 autofit 的技術。如此一來，字型描繪器自動忽略這些筆劃組字的指令， autofit 只能做筆劃微調，並沒有聰明到替這類的字型重新歸位與縮放筆劃，如此一來細明體與標楷體的顯示就像碎掉一樣。更糟糕的是，有不少的 Linux 發行商，編譯時強制預設開啟 autofit，關閉 BCI 的支援。(FreeType 中，這兩者是互斥的)
這裡舉Zaurus這個PDA上的QPDF為例：(QPDF源自於xPDF的計畫，後者發展為libpoppler)
下面則是開啟 BCI 後的正常情況。
另一個同樣採用 FreeType 的是 muPDF：
好消息是在2010年中，所有相關的軟體專利都已經過期了，自由軟體界再也不用擔心相關的侵權問題。所以自從FreeType 2.4版開始，已經是預設開啟BCI的支援。
不過光光是 FreeType 需要開啟BCI的支援，一些在編譯時期決定是否使用 FreeType 支援函式庫，如 libpoppler 與 muPDF 之流，都需要依據已開啟支援 BCI 的 libfreetype 重新編譯後才不會有問題。只希望很快在不久的將來，這些字型顯示破碎的問題，不再困擾使用 FreeType 函式庫的軟體了。
http://web.archive.org/web/20080430122831/http://www.freetype.org/patents.html (有更詳細的說明)
http://www.freetype.org/patents.html
Jserv's blog February 05, 2006
FreeType 新進展
http://blog.linux.org.tw/~jserv/archives/001489.html
Kanru's Adventure Journal/ archives/
Freetype 2.2rc3 + new Clearlooks
Mon 27 Feb 2006 01:29:02 AM CST
Freetype 2.2rc3，包含 olv 整合的 CJK autofit patch，對於中文字可以 render 的美美的 :)
http://kanru.info/blog/archives/211/
所以王子與公主從就過著幸福快樂的生活了嗎？其實不然。
微軟視窗內附的字型：細明體與標楷體可說是目前流通最大的字型。這兩個字型是由華康科技(日商收購後更名為威鋒數位)所製作，採用了筆劃組字的技術，進一步縮小的儲存空間，也內嵌了點陣字型對小字型做了最佳化。這裡筆劃組字的技術，就是借用bytecode的指令，把筆劃大小與位置的修正，提供給字型描繪器(render)。
就在這裡問題來了，把筆劃放到正確的位置與大小，需要BCI的支援。而大多數的情況，Linux 與其他使用 FreeType 的發行商，為了避免被專利所有權人收取權利金，都在編譯 FreeType 的時候，把 BCI 的支援關閉，改用 autofit 的技術。如此一來，字型描繪器自動忽略這些筆劃組字的指令， autofit 只能做筆劃微調，並沒有聰明到替這類的字型重新歸位與縮放筆劃，如此一來細明體與標楷體的顯示就像碎掉一樣。更糟糕的是，有不少的 Linux 發行商，編譯時強制預設開啟 autofit，關閉 BCI 的支援。(FreeType 中，這兩者是互斥的)
這裡舉Zaurus這個PDA上的QPDF為例：(QPDF源自於xPDF的計畫，後者發展為libpoppler)
下面則是開啟 BCI 後的正常情況。
另一個同樣採用 FreeType 的是 muPDF：
好消息是在2010年中，所有相關的軟體專利都已經過期了，自由軟體界再也不用擔心相關的侵權問題。所以自從FreeType 2.4版開始，已經是預設開啟BCI的支援。
不過光光是 FreeType 需要開啟BCI的支援，一些在編譯時期決定是否使用 FreeType 支援函式庫，如 libpoppler 與 muPDF 之流，都需要依據已開啟支援 BCI 的 libfreetype 重新編譯後才不會有問題。只希望很快在不久的將來，這些字型顯示破碎的問題，不再困擾使用 FreeType 函式庫的軟體了。
http://web.archive.org/web/20080430122831/http://www.freetype.org/patents.html (有更詳細的說明)
http://www.freetype.org/patents.html
關於細明體與標楷體顯示破碎的問題
某大老曾經說過「都 2006 年了還在搞輸入法. XD」，可是都 2011 年了，包含 Linux 下許多地方的細明體與標楷體，顯示破碎的問題還是都沒有解決。
背景知識
目前流通最廣的字型，是稱之為True Type Font (TTF)的格式。TTF 是採用向量的方式，以二階貝茲曲線來描述字符的外框(outline)，如此一來，無論是多大多小的字型，都可以透過數學式產生，不會有點陣字型放大時出現鋸齒方格的問題。
但這畢竟只是在有足夠解析度的理想情況，當需要顯示小字型的時候，問題就來了。TTF有幾種解決的辦法：直接使用最佳化過的點陣字型取代、採用半色調抗鋸齒、設計者提供筆劃資訊讓字型描繪器做最佳化(hinting)。最後者是將筆劃以bytecode來描述，需要一個直譯器來解讀。(bytecode interpreter, 簡稱 BCI)
開放源碼的FreeType引擎，完整支援這些最佳化的手段。在 Linux 下，過去普遍採用第一種解決法：螢火飛(id: firefly)以純手工的方式，補足文鼎字型的沒有內嵌點陣字的缺點。中國大陸的網友也發起了文泉驛點陣字型補足的計畫，在firefly的基礎上，由眾網友補足至Unicode約27842個漢字。因為單單使用半色調的方式，很容易在筆劃落在兩個圖素中時，造成朦朧不易閱讀的困擾。而不採用筆劃資訊最佳化的理由，是在於有三個蘋果電腦(Apple)的軟體專利。即是FreeType採用「無塵室」逆向工程開發出來，並不能讓 Linux 發行商免於權利金的支出。
相對來說，英文的問題小得多，主要是筆劃少且結構簡單，筆劃歪一點或糊一點也都還看得出來。當然後來發展出了次像素描繪(sub-pixel rendering)，甚至用特殊的演算法去「猜」得筆劃的骨幹，再進一步微調筆劃的位置到像素的中央(grid-fitting)，這個技術稱之為autohinting或autofitting。如此一來就避過的BCI的專利權問題。
參考資料：
http://tldp.org/HOWTO/Font-HOWTO/notgood.html
http://tldp.org/HOWTO/Font-HOWTO/bci.html
http://www.freetype.org/patents.html
http://avi.alkalay.net/2007/01/freetype-with-bytecode-interpreter.html
http://www.freetype.org/autohinting/background.html
http://www.linuxfans.org/bbs/archiver/?tid-92200.html
http://www.grc.com/cleartype.htm
背景知識
目前流通最廣的字型，是稱之為True Type Font (TTF)的格式。TTF 是採用向量的方式，以二階貝茲曲線來描述字符的外框(outline)，如此一來，無論是多大多小的字型，都可以透過數學式產生，不會有點陣字型放大時出現鋸齒方格的問題。
但這畢竟只是在有足夠解析度的理想情況，當需要顯示小字型的時候，問題就來了。TTF有幾種解決的辦法：直接使用最佳化過的點陣字型取代、採用半色調抗鋸齒、設計者提供筆劃資訊讓字型描繪器做最佳化(hinting)。最後者是將筆劃以bytecode來描述，需要一個直譯器來解讀。(bytecode interpreter, 簡稱 BCI)
開放源碼的FreeType引擎，完整支援這些最佳化的手段。在 Linux 下，過去普遍採用第一種解決法：螢火飛(id: firefly)以純手工的方式，補足文鼎字型的沒有內嵌點陣字的缺點。中國大陸的網友也發起了文泉驛點陣字型補足的計畫，在firefly的基礎上，由眾網友補足至Unicode約27842個漢字。因為單單使用半色調的方式，很容易在筆劃落在兩個圖素中時，造成朦朧不易閱讀的困擾。而不採用筆劃資訊最佳化的理由，是在於有三個蘋果電腦(Apple)的軟體專利。即是FreeType採用「無塵室」逆向工程開發出來，並不能讓 Linux 發行商免於權利金的支出。
相對來說，英文的問題小得多，主要是筆劃少且結構簡單，筆劃歪一點或糊一點也都還看得出來。當然後來發展出了次像素描繪(sub-pixel rendering)，甚至用特殊的演算法去「猜」得筆劃的骨幹，再進一步微調筆劃的位置到像素的中央(grid-fitting)，這個技術稱之為autohinting或autofitting。如此一來就避過的BCI的專利權問題。
參考資料：
http://tldp.org/HOWTO/Font-HOWTO/notgood.html
http://tldp.org/HOWTO/Font-HOWTO/bci.html
http://www.freetype.org/patents.html
http://avi.alkalay.net/2007/01/freetype-with-bytecode-interpreter.html
http://www.freetype.org/autohinting/background.html
http://www.linuxfans.org/bbs/archiver/?tid-92200.html
http://www.grc.com/cleartype.htm
Subscribe to:
Posts (Atom)