目前網上使用的中文破折號普遍存在「中間斷開」的問題，應該如何解決？

01-05

我今天剛寫信給 SunPinyin, IMKQIM 和 FIT 這三大 Mac OS X 第三方輸入法的作者，建議他們把默認的破折號換成「──」（兩個 U+2500，「BOX DRAWINGS LIGHT HORIZONTAL」，中間不斷的），而不是（在許多字體中都會）斷開的「——」（兩個 U+2014，即 em dash）。
@梁海有不同意見。他認為：

我剛才查看了一下各大字體里這個 glyph 的樣子，不是很贊成。一是因為遵循現有字元的語義很重要（Mac OS X 中文輸入法的那個省略號已經很麻煩了），二是 Windows 的幾個默認字體里這個 glyph 的效果不太好。一對 U+2014 (em dash) 的 CJK 用法，我覺得是合格的，一對 U+2500 確實是不斷，但在許多字體中的粗細和寬度都有問題。

此圖是含有 U+2500 的常見中西文字體的 U+2014 和 U+2500 的對比：
http://cl.ly/6Ggl
（上圖左為 U+2014，右為 U+2500）
由於 U+2500 的設計完全沒有考慮到用在這種地方，於是不論是寬度還是粗細都常常和漢字不配，於是綜合起來並不比 U+2014 好。

嗯，@Lawrence Li 在問題補充說明中已經把我的觀點基本都列出了。需要補充一點的是：U+2014（em dash）都是為拉丁小寫設計的，偏下；而 U+2500（BOX DRAWINGS LIGHT HORIZONTAL）是用來繪製表格的，居中——所以 U+2500 的高度本來就比 U+2014 更適合中文。

我認為以現在 CJK 標點的 glyph 之混亂，在網頁中破折號是否斷開並不是很嚴重的問題（而且在針對 Windows 的網頁設計中，只要讓 Arial 優先就能提供左右無空隙的 em dash），只要確保在正式排版、列印的文件中使用最佳的標點就好了。

但如果讓 Mac OS X 的標點符號變得更加混亂（現在已經有 Mac OS X 自帶簡體中文拼音輸入法使用 U+22EF 來作中文省略號的事情了，這個字元是不受 Windows 中文字體支持的），會給使用不同操作系統的用戶帶來很多困擾。

另外，突然有個想法：

對於個人網站等自己能控制 typography 細節的地方，我們可以給現在大家通用的破折號（兩個 U+2014）加上 HTML 標籤，變成 span.pozhehao，然後給這個 span 應用只包含中文字體的 font-family 屬性，比如：

font-family: "Hiragino Sans GB", "Microsoft YaHei", sans-serif;

這樣破折號就會順利使用中文字體的 glyph 了，就像現在許多精緻的西文站點給「」加上專門的標籤和樣式來使用花體一樣。

orz……我突然又有個想法：

應該讓西文常用字體中的 U+2014 在連續出現兩個時通過 kerning 或別的什麼字體參數來消除中間的空隙……

但其實我一直覺得 CJK 標點應該徹底獨立，否則對西文字體設計師來說是一種壓力，對中文用戶來說又很麻煩。

我個人還是覺得──（兩個 U+2500）順眼，比如這個問題的補充說明的第一段，——反倒偏低。不過我確實沒有仔細比較過在各個字體下和漢字以及拉丁字母搭配的效果，有待進一步觀察。

當然「──」也只是權宜之計，但在有中文字體重視「中文破折號不應該斷開」的問題之前，好像是最理想的選擇。

總體而言，我認為「不斷開」的優先級是最高的。

贊成 @江疆的看法，以語義為首，除非有一個（或兩個）更好的字元代表破折號，否者不要輕易更改，以破壞語義換取呈現效果，正被廢棄的 HTML 標籤 font 不就是一個反面教材么？剩下的交給字體和排版引擎。

IMKQIM的破折號是從PC上拷貝來的，沿用了以前PC的字元，而在Mac上斷開問題應該是和字體有關係的，宋體不斷，但黑體、新宋體都是斷開的。

十幾個版本之前的 Iosevka 裡面專門做了一個 2em 長的 em-dash，然後 ccmp 裡面有

sub emdash emdash by dblemdash;

不過後來為了對付 Linux 底下 fontconfig 識別的問題把這個 feature 給刪了，可能以後會做 ligation 字元處理這個問題：

feature ccmp { sub [emdash emdash.ligation] emdash" by emdash.ligation; } ccmp;

ps. 我至今都不知道怎麼讓我做的字體被 B 站播放器識別……

在日本電子書製作圈子裡也有這爭論，是要選擇正確但不通用的兩個Em Dash（U+2014），還是用繪圖的BOX DRAWINGS LIGHT HORIZONTAL（U+2500）/ BOX DRAWINGS LIGHT HORIZONTAL（U+2502）以求破折號一定連得起來。

處理上分為兩段：

第一階段：妥協

大多數的Reading System都不支援Em Dash相連，這時為求書的品質，只能用U+2500/U+2502處理，但卻不是好的處理方法，原因有：

語義問題：讀者讀到書裡有破折號，但搜尋不到；而直排書更沒人會想要輸入兩個直槓去搜尋；
呈現問題：U+2500/U+2502這兩個字都是字面做到滿，相對也會貼著前後，在直排中甚至會與前後一字相連，非常不好看。
CSS補正問題：直排中什麼符號要轉90度，什麼不轉當時還沒有定論，所以一定都要加上text-orientation: upright強制轉正，偏偏有些Reading System又有問題。

總之，初期先這麼辦，然後拚命聯合出版社和各書店反應，要求修正自帶字體與Render Engine修正到讓Em Dash相連。

第二階段：正規化

當Amazon、iBooks store、樂天Kobo這些銷量好的電子書店都修正以後，再請製作商將新書全面改用Em Dash。當然有些小的書店反應沒那麼快，不過在主流的RS上都沒問題，自然不會管銷售量小的，變成自然淘汰。

對繁體中文與日文來說，能簡單用兩個Em Dash搞定實在解決不少問題。

同樣的問題也出現在「·」MIDDLE DOT U+00B7上頭，這個字在繁體裡應該是全形，若一定要全形，就只能用?KATAKANA MIDDLE DOT U+30FB，但這個字是確實的日文符號，會有許多不可預期的小錯誤，幸好在Apple的System Font上，U+00B7會在直排時以全形呈現。

還有…HORIZONTAL ELLIPSIS U+2026，刪節號（日文稱三點リーダー）是日文標準用字，橫排時居中水平三點，但直排時應該是垂直中三點。不過也是有字型與Render Engine的差異。若要絕對確保置中，就要用上?MIDLINE HORIZONTAL ELLIPSIS U+22EF，但好死不死這個字是數學符號來著，在Android裡頭就豆腐給你看。

我是認為要講究就別將就，一旦妥協以後，該改的就會放著不改。

SunPinyin可以在用戶設置中自定義破折號…

這種問題也需要解決嘛？是發表論文影響到了嘛？不怎麼理解...可能是大家精益求精的態度吧，反正我是無所謂。

不能在計算機時代被鍵盤或輸入法快速打出的符號都會被歷史淘汰

不斷開怎麼能叫「破」折號呢？