阿拉伯文字排版與數位渲染的技術債

傳統阿拉伯文字排版與網頁渲染之間的差距

現代網頁瀏覽器無法原生執行傳統的阿拉伯文對齊（justification），這種對齊依賴於拉長字形而非拉伸單字之間的空格。雖然拉丁文字透過增加單字間的空白來實現對齊，但古典阿拉伯文字排版使用 taṭwīl（或稱 kashida）——即在特定的字母對之間延伸連接筆劃——以確保兩側邊界齊平，同時不破壞文本的視覺結構。

目前，CSS text-align: justify 對於阿拉伯文預設採用拉丁式的單字間距，這在阿拉伯文字傳統中在美學上是不正確的。要在網頁上實現真正的對齊，通常需要手動插入 U+0640 TATWEEL 字元，這種做法會降低搜尋能力、破壞螢幕閱讀器，並在文本重排（text reflow）時失效。

阿拉伯文字塑形的複雜性

阿拉伯文在本質上是草寫的，這意味著字母必須根據其在單字中的位置改變形狀。單個碼點（codepoint）必須以四種形式之一進行渲染：孤立型（isolated）、字首型（initial）、字中型（medial）或字尾型（final）。

塑形引擎的角色

為了正確渲染阿拉伯文，軟體必須使用塑形引擎（例如 HarfBuzz）在渲染時套用 OpenType 功能。此過程包括：

位置變化：根據鄰近字元選擇正確的字形（glyph）。
連字：套用必要的 (rlig)、標準 (liga) 和酌情 (dlig) 連字。例如，lām-alif 連字對於識字率至關重要。
標記堆疊：正確地在垂直方向上定位元音符號和變音符號（diacritics）。

如果沒有塑形引擎，文本將會渲染成一系列斷開的、孤立的字母，從左到右排列，這是舊版 PDF 生成器、某些 Python 函式庫（如 matplotlib）以及收據印表機常見的錯誤。

雙向（Bidi）佈局與「說謊」的游標

阿拉伯文文本通常存在於混合內容環境中（例如，包含英文版本號或 URL 的阿拉伯文散文），這會觸發 Unicode 雙向演算法（UAX #9）。該演算法根據字元的方向性特徵將字元解析為「序列」（runs）：阿拉伯文是強烈的從右至左（RTL），拉丁文是強烈的從左至右（LTR），而數字則是「弱」的。

常見的 Bidi 錯誤

游標跳躍：由於螢幕上的視覺順序與記憶體中的邏輯順序不同，光標（caret）經常在序列邊界處發生意外的跳躍或回退。這種不一致性在不同的瀏覽器和編輯器中各不相同。
範圍翻轉：在阿拉伯文段落中，像 "10-20" 這樣的範圍可能會渲染成 "20-10"，因為連字號是中性的，而數字被重新分類為阿拉伯數字，導致序列根據規範進行了交換。
標點符號位移：當周圍的上下文方向改變時，結尾的感嘆號或句點經常會「傳送」到行末的另一端。

數字問題

由於在不同地區使用三套不同的數字集，阿拉伯文渲染變得更加複雜：

阿拉伯-印度數字 (٠١٢٣٤٥٦٧٨٩)：用於埃及、蘇丹、黎凡特、伊拉克和海灣地區。
拉丁數字 (0-9)：主要用於馬格里布地區（摩洛哥、阿爾及利亞、突尼西亞）。
擴展阿拉伯-印度數字 (۰۱۲۳۴۵۶۷۸۹)：用於伊朗、阿富汗和巴基斯坦。

除了字形之外，數字的雙向行為也存在問題。根據 UAX #9 的 W2 規則，如果數字前面有阿拉伯字母，數字會被重新分類為 ARABIC NUMBER，這會改變中性字元（如連字號）在它們周圍的行為，經常導致電話號碼或日期排序錯誤。

歷史技術債：從抄寫員到「簡化阿拉伯文」

數位化處理阿拉伯文的掙扎是數世紀以來試圖將複雜的腳本放入僵化的機械系統的結果：

早期印刷 (1514)：早期的活字印刷產生了斷開的、不識字的字母形狀，因為排字工不理解該腳本的草寫要求。
Bulaq Press (1820)：埃及政府資助的努力最終透過為每個位置形式和連字創建數百個獨立的金屬字模，實現了高品質的文字排版。
簡化阿拉伯文 (1958)：為了符合 Linotype 機器 90 通道的限制，出版商 Kamel Mrowa 協助創建了「簡化阿拉伯文」，它將字首型融合為字中型並捨棄了連字。這種以效率驅動的簡化變成了新聞室和打字機的全球標準。

志願者的基礎設施

現代網頁上大部分的功能性阿拉伯文渲染，是志願者而非產業投資的成果，而非商業勞動：

Amiri Font：由 Khaled Hosny 開研發，他是一位醫生，為了復興 Bulaq Press 字體，自學了字體工程學。它仍然是目前最好的免費 Naskh 字體之一。
HarfBuzz：Chrome 和 Android 使用的塑形引擎，由 Behdad Esfahbod 和 Khaled Hosny 等志願者大力開發。
SIL International：為翻譯工作提供了關鍵的字體支持（例如 Scheherazade New）。

儘管有這些進展，關於 OpenType jstf 表（用於對齊優先級）的爭議仍然存在。由於瀏覽器廠商並沒有優先實施這些表格，由抄寫員在 10 世紀解決的傳統書法對齊問題，在現代網頁技術棧中仍然未被實施。