[CLReq]中文排版规范前期讨论

整理一下已有的论点，期待小组 的大家对这些问题的看法，讨论时候请抄送一下
兴趣小组:)

*Bobby Tung:*

現在提出的排版規範，大多數都是就CSS規範作調整，�@部分按照時間，大概也都
落 到CSS 4去了。

但有一項較急，就是<Ruby>的用法，�@一項是與HTML 5相關的。台灣�@邊的注音是
一回事，但拼音�@得更急切。

舉個例子：在一個全加拼音的文字段落上，假設全部標拼音，像張（Zhang）�@樣
一個字，就會因為Ruby的寬度影響到字距。

因為Ruby也就CJK在用，日本需求最完善，台灣注音我試著處理，但目前鮮少有 拼
音的需求出來，還得請各位撥冗看看有哪些

地方要提出了。附上一些文檔：

?W3C HTML Ruby Markup Extensions
http://darobin.github.io/html-ruby/

?CSS Ruby Module Level 1
http://www.w3.org/TR/2013/WD-css3-ruby-20130919/

?Use Cases & Exploratory Approaches for Ruby Markup
http://www.w3.org/TR/ruby-use-cases/

?汉语拼音正词法基本规则GB/T 16159-2012
�@就請自行找載點。


*Chen Yijun (@ethantw):*

希望文檔能盡可能以Markdown格式發表，如此一來，文本可有一定的規範性， 並
降低每位編寫者的風格歧義、不必要的資訊得以袪除，也能即時在GitHub上預覽。


*Xidorn Quan:*

今后相关的讨论可以抄送中文兴趣小组的邮件列表，以让更多人有机会参与进来。同时这样也可以在公开领域留下讨论记录，方便将来查阅。


*江疆：*

同意 ethantw 关于用 Markdown 格式编辑的意见，另外既然项目已经放在 github
上，不如就用 GitHub Pages
的功能 [2] 通过 Jekyll 组织页面？各位没有意见的话我可以把 [3] 的 gh-
pages 分枝建立起来。


*梁海：*

@Bobby，我有个疑问——

tCLreq 草稿中涉及 ruby 的部分让我有一点困惑。
按照我的理解，所有附加在主文本流之上的小字语音（以及较少用的，词义）标注
都叫作 ruby 呀，包括日文的振假名、包括台湾的注音符号标注和大陆的汉语拼音
注音。W3C 的 Ruby Annotation 方案也覆盖的是这整个范围。
但 tCLreq 草稿中说「對繁體中文而言，Ruby不是傳統的排版方式」，加上下面的
范例列举，似乎是用「Ruby」特指了小字号的中外文对照标注？


*Bobby Tung:*

思路大概是�@樣的——

?Ruby Annotation是將注音、拼音、假名等視為同一件事的技術處理方式。
?Layout Requirement是從傳統印刷排版出發，提供技術上處理作為參考。
?傳統印刷排版，拼音與注音都是獨立的一件事。
?中文書輕小說使用的Ruby，也與日文傳統的振り仮名不同，多為英註漢字、漢字
註英、漢字註漢字，所以獨立處理。


*梁海：*

#1 讨论简繁两版及日文版的关系

我收到邀请时第一个疑问就是：简繁两版 CLreq 应当如何协调？

我想，不论厂商还是个人开发者还是爱好者（JLreq 对 typography 爱好者来说是
个宝藏，我们经常参考那里面的内容），面对简繁两份 CLreq 都会感到很麻烦。
而且这简繁两份文档注定不会有太多的差异（或许能差个 10–20%？），甚至和日
文版都会有不少重叠的内容。
在这些大体相同的文档之间把握不同的部分会很痛苦。

中文版合并至日文版近期来看不现实，那么有多少日文版中已存在的内容有必要在
中文 版里重复出现？应当如何协调中日版本之间近似及不同的内容？交叉引用
吗？甚至我们只撰写差异？
如何设定这个内容覆盖范围的限度？「独立可读」？或是「依附于日文版」？

繁体和简体中文版本能否合并？
- 不合并的话，二者如何保持协调？（至少两份文档的主体结构应当平行吧？）如
何向读者强调简繁两版的差异与一致之处？文末提供对照表？
- 合并的话，如何融合并合理呈现双方的内容？（两岸连字体类别（明体 vs 宋
体）这样的基本术语都冲突耶！）能否在每一章节对双方共性进行综述然后分别指
出差异？

中文维基百科的经验是否有可借鉴之处？
W3C、Unicode 之类的组织是否有类似的「平行」文档可供参考？


#2 参考 JLReq 拟定 sCLReq 提纲

我刚刚提交了 https://github.com/w3c/CLReq/blob/master/sclreq/outline.md
这个文件，把 JLReq 的整个目录扔进去了。
各位可以立即开始浏览（不必细看）JLReq，看看 JLReq 的各个章节是否有必要出
现在 sCLReq 中，有任何成型不成型的想法也都可以扔在相关章节处。
JLReq 篇幅相当长。各位可以从自己之前仔细读过或感兴趣的部分开始分析。

比如：

sCLReq 的对应部分会不会与 JLReq 中的这一章节雷同以致直接翻译就好了？或类似？
或者 JLReq 的这一章节涉及日文假名之类日文独有的问题，所以 sCLReq 中根本
就不会存在相关内容？
sCLReq 的这一章节会涉及哪些国家标准？
谁会是这一章节比较好的主笔人选？
另外其实也不妨在 outline.md 的最后建议一些 JLReq 里没有的章节。

这样我们把 JLReq 梳理一遍，sCLReq 的内容架构就大体上有了，而且各位可以由
此熟悉 JLReq（我也没有全文看过，从来都是零零星星查阅），毕竟 JLReq 是最
重要的参考。
这一阶段应该不必太在意与 tCLReq 的协调工作。先用比较单纯的思路分析
sCLReq 和 JLReq 的关系即可。


*Xidorn Quan:*

我想既然中文版近期不可能与日文版合并，至少应该要做到独立可读比较好。如果
能大 体保持结构的相似，将来需要合并的话也不会很麻烦

个人感觉还是合并比较好，毕竟相似性应该会很高。不过撰写时或许可以先分开，
最后 再整理合并。具体的合并事宜可以留到那个阶段再讨论，毕竟究竟有哪些内
容相似哪些内容不同，现在都还无法完全确定。你提到的基本术语冲突 的问题，
也可以等到具体内容确定以后，再根据它们出现的位置和频率做具体讨论。

中文维基基本上就依赖它们的繁简自动转换了，等于一份文档出两个（实际上是五
个） 不同的自动互转的版本。如果这份文档一直是中文的，这样做应该没什么大
问题，但考虑到要翻译成英文，有一些术语差异或许需要考虑。


*Bobby Tung:*

在TPAC上的討論曾有考量過�@點。JLREQ編撰前後歷時五年，我們�@然不會花 上�@
麼久來處理。不妨將簡體與繁體中文排版需求視為異同處理，也能跟上目前已經提
出CSS規範的立即參考。

文件的簡體與繁體以及術語的處理可以用語表來處理。但文字體系上我還是傾向不
合 併，而是先以表格化的方式來做差異處理。不然對西方讀者來說，同樣的細節
在閱讀時要於兩種概念轉換，也不易閱讀。

另附上Hachett Livre的Dave Cramer正在撰寫的Latin Requirement作為參考。

http://w3c.github.io/dpub-pagination/



*Chen Yijun (@ethantw):*

我個人認為不應該�@樣簡單地分化繁簡詞彙。無論是中文原生詞彙或翻譯名詞，有
時候 即使是在同一個地區，也會有二至多種稱呼，在�@些名詞沒有特定一種具更
強勢的使用頻率時，若能選擇繁、簡中文地區皆可接受的、相容或相同 的那一個
會是比較好的方式。

比如中文字體的四大分類，在Bobby的文檔中使用了「明、楷、黑、宋」，若能改
用「宋、楷、黑、仿宋」，不僅減少曖昧和歧義，也能相容於大陸的詞彙體系，且
後者對繁中使用者來說亦不感陌生。

我並非更偏向簡體中文或繁體中文的其中一種。我僅是認為，大如W3C�@樣的組
織， 其規範的編寫如果能以「國際中文」「易讀中文」為出發點，求同存異，如
現在的英文規範可以適用於全英文地區甚至全世界，中文也許能有一種 相容於各
地差異的中立版本的詞彙，讓區別只存在於「字形」和「繁簡」�@種不可抗力因
素，那是再好不過了。

對於各種具爭議的繁簡詞彙，我傾向於應分別提出來討論，儘可能選擇*一個*雙方
面 讀者皆可接受的、更好的詞彙，並以附錄的方式整理其他的語彙。若真的無法
相容，再行分化。

當然，參考維基百科和其他國際組織的文件編寫方式是現行較實際的方式，也許各
種方 法我們都能試驗一下。

-- 
Best Regards,
Xiaoqian (Cindy) Wu