風吹草動

首先，為了瞭解打包的概要，所以照著〈 How to create a GNU Hello RPM package/zh-tw 〉一文做了一次，約略知曉整個流程。 接著開始編輯 cwtex-q-fonts 的 spec 規格，這就像食譜一樣，只要寫得好，廚師就能直接煮出來。 嗯，講到這，我們得先準備好食材才行！ 先切換到 ~/rpmbuild/SOURCES 擺放好所要的食材。也就是請前往 cwtex-q-fonts 的專案網站下載 0.2 版的封存檔，然後放到這個資料夾裡預備。抓下來的檔案叫做 cwtex-q-fonts-v02.tar.xz。 不過由於字型打包的 spec 樣板不在預設打包者工具中，要另外準備。所以如果你只有安裝前文所提及的 @development-tools 與 fedora-packager 的話還不夠，需要另外安裝： sudo yum install fontpackages-devel 裝好後，就能利用下列指令參照內含多款字型的軟體包其 spec 樣板： cd ~/rpmbuild/SPECS rpmdev-newspec -t fonts-multi cwtex-q-fonts 接著就來編輯 cwtex-q-fonts.spec 吧！用 vi 或是 gedit 都可以，順手就好。 利用樣板生成的檔案中，可以看到由 < 與 > 括住的地方，那是讓打包者替換所要內容的。①、②、③ 等數字編號，是小提示，拉到檔案最下方有註解解釋那段作什麼用途，或是選用填入之類的，整份檔案編輯完成後，記得把數字編號與最下方不再需要的註解移掉。 由於是第一次打包內含多款字型的字型包，不是很有頭緒，因此下載了一些字型 source rpm 來參考。 cd ~/rpmbuild/SPRMS yumdownloader --source google-droid-fonts cjkuni-uming-fonts wqy-microhei-fonts 用解壓縮軟體打開，找到附帶的 .spec 檔研究研究。 參考用 spec 檔開啟完後再回去 SPECS 資料夾。 cd ../SPECS 繼續改編 cwtex-q-fonts.spec 檔。 #global archivename %{name}

Justfont 是個 中 文 雲 端 字 型 (web font) 服 務，產品主推香港人 柯熾堅所 設計的信黑體。雖然信黑體在 Justfont 的廣告中說有多好、多高品質、多不可思議，但實際上讀者應該自己用眼睛詳細判斷是否如實，別一味被廣告手法牽著走。 個人對於信黑體的看法僅只於：手做字型數位化本身就是個大工程，柯老師所做確實辛苦，風格可明確展現出手作的生命感、變化感，這正是某些「藝術感」所需要的必備條件。但透過 Justfont 所 呈現出的 字型效果在一般螢幕上 (非高解析度螢幕，如 Retina 等高 ppi 螢幕) 仍非完美，細看可發現許多字的內部筆劃粗細並不一致，遇到偽粗體、或大字時缺陷將更加明顯；小字筆劃重疊而影響閱讀的缺陷也不難發現；個人看來該字型目前僅有在高解析度螢幕上表現較佳而已。但畢竟向量字型在螢幕上輸出本來就會遇到這些事，那些高品質的字型就是不斷在花心力解決這些問題。不過既然 Justfont 是信黑體代理商，這樣廣告也無可厚非。 Justfont Blog [1] 則是個從字體出發探討設計的部落格，由許多關心「字」的人經營，除了分享許多字型相關感想、比較、評比外，也教育大眾字學 (typography) 的相關知識。個人非常推薦這個部落格上的內容 (廣告訊息可以乎略掉之外)。 每次看到這部落格上的某些文章，就會開始覺得要趕快繼續推動開放字型的未來發展才行，或應該好好來設計一套字型，或是好久沒有寫書法了之類的感想。 最近上面有篇「 大眾字型學(3)：Word 預設中英搭配有什麼問題？ 」[2]，正好在探討我一直在關注，想要處理的中英搭配協調議題。只不過它是探討 Windows 上微軟 Office 的預設中英字型，而不是 fedora 中 GNOME 3 界面預設字型 Cantarell 的中文字型搭配。 有興趣的人可以一看。 真不明白為什麼 fedora 的 i18n 組竟然連 sans-serif 與 serif 之間的差異都不甚明瞭，還能掌控字型相關領域的決定，製作出一堆奇異、令人嘆為觀止的 fontconfig 組態檔。如果真那麼愛點陣，那麼把小字沒襯線的點陣字部份嵌進黑體裡不就好了，亂匹配字體類別就是胡搞瞎搞、不僅不合規範更是絕不該做的骯髒補救手法。 如果最近能快速忙完 LibreOffice 4

話說，昨天被 Blender 愛好者 何彥儀 ，阿彥，邀請分享當初翻譯 Blender 的心路歷程、目標與理念。 雖然說沒有什麼心路歷程，但確實有一段很長的故事，且聽我娓娓道來。 翻譯歷程 要講到 blender，就必須從我接觸 Linux 開始說起。 我個人從 2003 開始接觸 Linux 作業系統，最早是臺南縣網 ols3 主持的 B2D 系統，裝好後就是調校好的 Debian GNU/Linux 系統，很多方便的工具早就裝好了，深深讓我驚豔並從 Windows 轉用 Linux。那時最常上的網站不外乎 Knoppix 技術交流網、自由軟體技術交流網、摩托學園，也開始參與社群討論。 2004年底在摩托學園上看到阿信板大一篇「 Ubuntu 的使用感想 」後 [1]，也開始用起 Ubuntu。2005年6月11日 Ubuntu-TW 開站便馬上註冊，偶爾關注並參與上面的討論。 2007年2月11日，看到魏藥在 Ubuntu-TW 上的「[ 3D設計]Blender 」一文 [2]，當下把 2.42a 安裝起來試用，除了界面還是英文之外，此外操作上也有點門檻。文中也有提到，當時只有簡中版。於是心中就有個想法，如果這套軟體可以繁體中文化 (這詞也就是今天說的正體中文化)，不就可以再降低門檻嗎？遂以匿名身份留下了「要怎樣去翻譯阿？老實說我不習慣看太多英文」這樣一段話，不過沒有得到相關回應，轉而自行搜索相關資訊。 找到的第一項資訊就是 blender wiki 上對國際化的說明文件： Interface Internationalization [3]，跟著文件描述走，得知方法有兩種，一是用 blender 的源碼自己做出 po 檔；二是 Blender source distribution 中與 Blender websvn 中都有 po 檔，當時整理得最完整的是德語的 de.po，版本是 2.4x，所以可以直接拿這個版本作為模板，酌情參考簡中翻譯進而翻譯出正體中文版，可以免去自己做 po 檔的麻煩。 文件最後方提到如要提交翻譯，請寄送到 bf-committers@blender.org，所以同時也加入 bf-committers 郵遞論壇，追蹤開發資訊中是否有提到翻譯相關事務，但除了開發上的討論外，始終沒有看到相關翻譯討論。

3D 軟體中有個著名詞語叫做 Render。 目前有各種翻譯，最常見的「算圖」，次常見但越來越普遍的「渲染」，比較少見的「算繪」及「彩現」。我就來一一討論翻譯是否適切。 首先，得了解什麼是 Render 才有辦法討論下去。以電腦圖形領域來說，Wikipedia 上的 Render (Computer Graphic) 條目一開頭便寫到： Rendering is the process of generating an image from a model (or models in what collectively could be called a scene file), by means of computer programs. 簡單翻成中文，Render 就是指透過電腦程式製作出模型 (或是放在一種整體來說稱為「場景檔」內的眾模型) 影像的一道程序。這道程序主要有兩個步驟，一是電腦計算模型的材質紋理如何與光照、光影著色法...等設置交互影響後結果為何，二就是將成果以像素一點一點地呈現成影像給使用者。 那麼口語中呢？Oxford dictionary 中提到，Render 作動詞用時，其實是指藝術性的「表現手法」： represent or depict artistically: the eyes and the cheeks are exceptionally well rendered   perform (a piece of music): a soprano solo reverently rendered by Linda Howie   translate: the phrase was rendered into English   Computing process (an outline image) using colour and shading in order to make it appear solid and three-dimensional: he is forced to render images by intermixing pixels of a few basic colours 不管是繪畫領域，如描繪圖畫（把心中靈感翻譯出來給觀眾體會）；音樂領域，如

就像當初打算的，想要翻譯 LibreOffice Getting Started Guide 與 the Essential Blender，先上線了《LibreOffice 入門指引》，再來是《Blender 精要》。 目前 Blender 精要翻譯了第一章，有興趣的可以前往閱讀。我會在有空之時持續翻譯更新這部作品。 本書網址： http://the-essential-blender-zh-tw.logdown.com/ 至於 LibreOffice 入門指引，目前很高興 Jia-Jun Xu 加入行列，我們想以協作方式處理個幾章試試，現以第二章為先，採 Google Drive 試驗。不過必竟是開放式授權，反正發行後想轉貼到哪裡去都可，只要符合授權條款就行。 翻譯這本書時也有些感想。Blender 精要是本很流暢的書，揉合了文本與工具書兩種特點，所翻譯時很舒服，完全沒有那種是翻譯程式介面或是指引手冊那種無趣死板的感受。所想的只是怎麼翻譯得更通順，怎麼表達得更好，所以個人還滿享受翻譯這本書的，哈哈。XD

這兩個專案是本人這一兩年內，除了 GNOME、fedora 外所主力翻譯的；而兩者都有個共同特色，就是專案龐大！接觸這麼久之後，也有些感想。 LibreOffice 有 6 個組件，Writer、Impress、Calc、Drawing、Math、Base。翻譯檔四散在各個資料夾中，非常模組化，幾乎一個翻譯檔就是管一個同質畫面 (例如某某對話方塊，或是某某偏好設定視窗) 中的字串，大部分都很好翻譯，但少數卻非常專業 (例如 Calc 中有許多統計、經濟上的函數，Base 中有許多資料庫術語)。 由於 LibreOffice 的翻譯是承接自 OpenOffice.org，很多東西的翻譯都是前人留下來的遺產，加上沒有任何交接資料，要維持術語的統一性是一大課題。當新字串出現時，如果機器找出的翻譯建議 (從以前的資料去比對，然後找出相近的作建議) 很奇怪，就開始思索著翻譯合不合適，有時查詢一下之前的翻譯，發現錯得離譜，有時則發現同個字有數種翻譯而沒統一；或深入追查材發現翻譯成果竟然與原文無關，但卻是介面上可以看懂的描述，想不懂前人是怎麼知道這個字串會出現在這裡的。如果前人是親自編譯程式，邊翻邊看成品，那真是下了好大一番時間與精力才能完成的啊！這時候就知道，我必須得親自看過每個翻譯檔中的每個字串，並且把模糊的翻譯 (個人覺得有疑義的) 與確認的翻譯 (個人覺得沒問題的) 記錄下來，才有辦法維持術語的一致性，也才能修改掉那些根本徹頭徹尾就是錯誤的翻譯。這也是我從 Blender 翻譯中體認到的，想深入瞭解該怎麼翻譯，就得對全貌有個印象，一旦翻譯負責人沒有親自一個一個看過，那麼總會是霧裡看花，或許重大錯誤一直都在那裡，而每次修正的都只是雞毛蒜皮罷了。 當然，如果今天是一個翻譯團隊就不是這樣了，一般的翻譯者無須一個一個體會翻譯，而是需要依照既定的翻譯撰寫規則與術語表去翻譯，遇到不確定或是有疑義的字再拿出來檢討，再據此修正翻譯即可。這時翻譯負責人所需要作的，就是根據他獨有的整體概觀，評判翻譯是否真有問題，以及新翻譯該如何才能貼合既定風格；如果遇到一個詞語可能有不同人有不同意見，再以其專業決斷如何處置，可能擇優，可能擇一，可能皆收以測試，也可能擱置；如同 Linus 對於 Linux kernel 開發的管理一般。 Blender 則很特別，i18n 的負責人把所有介