Where I write about tech and life.
-
JSON Web Tokens
What are JSON Web Tokens? Can it really be used to replace traditional session cookies? This article is a note made while studying JWT.
-
Simpler way to load CSS asynchronously
在 Smashing Newsletter 看到的,只要 標籤就可以簡單把 CSS 變成非同步讀取。
-
CSS Text 3: Segment Break Transformation Rules
去年年底,我利用閒暇時間1修好了 Firefox 的 Segment Break Transformation Rules 實做(Bug 1081858)。從 Firefox 52 開始,HTML 裡面中文與中文之間的換行,瀏覽器排版時不會顯示為空白。
-
CSS Text 3: Segment Break Transformation Rules
At the end of last year, I used my free time1 to fix Firefox Implementation of Segment Break Transformation Rules (Bug 1081858). Starting from Firefox 52, the line breaks between Chinese and Chinese in HTML will not be displayed as blank in the browser.
-
Source Han Sans & FreeType
前陣子 Adobe 和 Google 聯手各自用不同的名字釋出了一款新的中文黑體字形,Source Han Sans 思源黑體,也叫做 Noto Sans (反腐字?)。開心試用之後,把系統字形都換過來,也開始想要怎麼樣才可以達到最佳的顯示效果,尤其是 Adobe 和 Google 曾經給 FreeType 貢獻了 CFF 字形引擎的改進,思源黑體也是以 CFF 技術設計,終於可以試試看中文的效果怎麼樣了啊! 我這邊使用 FreeType 的工具程式 ftview 來測試不同參數設定下的顯示效果,同時也附上相對應的 FontConfig 設定。可以發現不同設定下的顯示差距還蠻大的: Auto-hinter, hintfull, grayscale anti-alias 首先是使用 FreeType 的 autohint, hintfull 其他用預設值,這應該是滿多人使用的設定,可以看到 autohinter 有很強烈的瘦身效果,把 Normal 的字變成幾乎是 Light 了。 Auto-hinter, hintslight, grayscale anti-alias 再來是使用 hintslight,許多人用以取得類似 Mac 上面的渲染效果,卻不知道 hintslight 會自動使用 autohint,這張的效果和上面類似但是略為粗了一點。思源黑體使用…
-
GCIN in Debian is seeking co-maintainer
尋找 GCIN co-maintainer HIME 的事件鬧的沸沸揚揚,一切的起因之一就是有人認為 HIME 會取代 Debian裡面的 GCIN,這是什麼狀況呢?因為在 Debian 裡面把 GCIN 棄養 (orphan)的就是我,似乎也有必要說明一下。以下提到 GCIN 都是指 Debian 裡面的 GCIN。 最早的 GCIN 維護者是 caleb,後來他因為不再使用 Debian 所以開始找其他人幫忙維護,而我成為 Debian Developer 的初衷就是要幫助本地的使用者有習慣好用的套件可以用,所以就接下了這個位子。當時我也有使用 GCIN 所以就算劉老大 (eliu) 每兩三天就有新版本我也還可以跟上,只是沒有辦法把套件整理的乾淨點,後來不用 GCIN 了,套件的更新就漸漸脫節,因為有 Luna Archiver的存在也讓我有偷懶的藉口,最後發現花在這個套件的時間與 Debian 的Popcon 統計不成比例,就決定把套件給棄養了。 Debian 對於被棄養的套件的處理方式是,如果沒有出什麼大問題就會由 QAteam 來管理,但是如果有人提出 RM: RoQA 的要求,因為使用者 (Popcon) 少且無人管理,就有可能被移出 Debian,但無正當理由甚少有直接使用新專案取代舊專案的狀況,因此 Debian 要使用 HIME 取代 GCIN 純粹是誤解而已。…
-
Not Again, MingLiu!
長話短說,從 FreeType 2.4.4 (2010-11-28 release) 開始,只要編譯的時候有啟用 BCI (Byte Code Interpreter) ,新細明體就不應該會破掉了,只是因為一些原因 (下面詳述),一直到 2.4.5 (2011-06-24 release) 才算是完全解決。 這個問題牽扯到許多有趣知識,所以我決定作個筆記以免以後忘掉。 TrueType 首先是一些名詞解釋,TrueType 是常見的字型 (font) 格式,由 Apple 發展,後來被 Microsoft 採用並發揚光大;雖然沒有經過任何國際組織的標準化,在當時儼然已經成為業界標準 (de facto standard)。 TrueType 使用的檔案格式又稱為 sfnt 格式,由許多不同的表格 (table) 組成,每個表格由四個字的標籤 (tag) 表示,其中我們最關心的是 glyf 這個表格,因為所有的字符 (glyph) 都儲存在這個表格內。每個字符僅僅紀錄了形狀,要知道某個編碼的某個字元 (character) 是對應到哪個形狀,還要透過 cmap這個表格來查詢;也有一個字沒有相對應的字符,或是沒有任何字對應到某個字符的情況。 參考資料: Hinting (Instructing) TrueType 是一種外框字型 (Outline Font),也就是說每一個字符都是以向量圖形的方式呈現,理論上可以在各種不同解析度下呈現相同的形狀。 但是越是在低解析度的時候,由於可用的像素較少,越容易遇到邊界的表達能力問題,如右圖的 M 字,若沒有對齊像素點的話,呈現出來的圖案就會比較瘦長且左右不對稱,如果稍微向右移動並加寬一點,呈現出來的圖案就會比較接近原本向量圖形所預期的形狀;這個動作正是 Hinting…
-
Speed comparison C vs Common Lisp
昨天看到有人轉噗一則 StackOverflow 上面的問題,內容是問他分別用 C,python, erlang 與 haskell 寫了 Project Euler 的第十二題,但是haskell 版本慢得不像話,該如何改進? 以下是苦主的原始 C 語言版: 我的執行時間約為 5.48s 手癢想看看據說可以編譯出不錯的機器碼的 Common Lisp 速度怎麼樣,於是第一個版本如下 (用 sbcl 執行): 還不錯,11.192s,這個版本採用原文中給 haskell 的建議,使用 rem 而不是 mod,可以加快一點速度。再給一點關於型別的提示,然後把第一個 function inline,第二版可以跑出和 C 版本差不多的成績 5.563s 🙂 純粹湊個熱鬧而已,有興趣的人可以試試看把 loop 改成和原文其他語言一樣使用遞迴來實做,大部分 Lisp 都有做 TCO,速度應該差不多… 結論:Common Lisp is awesome 😉
-
Literate Programming
Let us change our traditional attitude to the construction ofprograms: Instead of imagining that our main task is to instruct acomputer what to do, let us concentrate rather on explaining to humanbeings what we want a computer to do. ― Donald Knuth. “Literate Programming (1984)” Thinker 的一篇心靈與程式碼的協奏曲提到程式由後往前寫似乎比較符合思考的方向,不禁讓我想到 Knuth 提出的 Literate Programming 方法;其實我們思考的順序有時是跳躍式的,用 LP 的方法可以完全跳脫先後關係,用自己喜歡的順序來寫,我覺得也可以稱為碎碎唸寫法。 用…
-
Android: Wakelocks and TuxOnIce
最近為了把 TuxOnIce 整到 Android 上面,著實把 Linux 的電源管理系統中關於 suspend 與 hibernation 的部份研究了一下。而 Android 為了增加待機時間加入了 wakelock 的機制,讓情況變得更加複雜。 TuxOnIce TOI Patch TuxOnIce 簡稱 TOI,前身是 Software Suspend 2,是一個長期在 linuxupstream 以外耕耘的一個休眠補釘,相較於早期整合到 linux kernel 內的swsusp,TOI 的功能非常豐富,可以指定把記憶體內容儲存到多種不同的位置,如檔案或置換空間,還可以選擇不同的壓縮方法。 首先幫 ARM 平台加上基本的休眠功能,使用 Hiroshi DOYU 的 patch: http://article.gmane.org/gmane.linux.power-management.general/20543 然後到 TOI 網站下載最新的 3.2 補釘,打上去的時候會有一些衝突但是都還滿容易解決,要注意的是某些衝突是看不出來的,例如因為函式移動位置而造成重複定義,要小心檢查。 然後因為 TOI 對於非 x86 平台有一些假設現在已經不適用,所以需要修改 https://gitorious.org/0xlab-kernel/kernel/commit/e551caf OMAPFB 使用 Pandaboard 加上 Android 測試才發現從休眠醒來後…