整理一下已有的论点，期待小组 的大家对这些问题的看法，讨论时候请抄送一下
兴趣小组:)
*Bobby Tung:*
�F在提出的排版����，大多�刀际蔷�CSS����作�{整，�@部分按照�r�g，大概也都
落 到CSS 4去了。
但有一���^急，就是<Ruby>的用法，�@一��是�cHTML 5相�P的。台�尺@��的注音是
一回事，但拼音�@得更急切。
�e��例子：在一��全加拼音的文字段落上，假�O全部�似匆簦�像��（Zhang）�@��
一��字，就��因��Ruby的��度影��到字距。
因��Ruby也就CJK在用，日本需求最完善，台�匙⒁粑以�著��理，但目前�r少有 拼
音的需求出�恚���得��各位�苋呖纯从心男�
地方要提出了。附上一些文�n：
?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
�@就��自行找�d�c。
*Chen Yijun (@ethantw):*
希望文�n能�M可能以Markdown格式�l表，如此一�恚�文本可有一定的����性， �K
降低每位����者的�L格歧�x、不必要的�Y��得以��除，也能即�r在GitHub上�A�[。
*Xidorn Quan:*
今后相关的讨论可以抄送中文兴趣小组的邮件列表，以让更多人有机会参与进来。同时这样也可以在公开领域留下讨论记录，方便将来查阅。
*江疆：*
同意 ethantw 关于用 Markdown 格式编辑的意见，另外既然项目已经放在 github
上，不如就用 GitHub Pages
的功能 [2] 通过 Jekyll 组织页面？各位没有意见的话我可以把 [3] 的 gh-
pages 分枝建立起来。
*梁海：*
@Bobby，我有个疑问――
tCLreq 草稿中涉及 ruby 的部分让我有一点困惑。
按照我的理解，所有附加在主文本流之上的小字语音（以及较少用的，词义）标注
都叫作 ruby 呀，包括日文的振假名、包括台湾的注音符号标注和大陆的汉语拼音
注音。W3C 的 Ruby Annotation 方案也覆盖的是这整个范围。
但 tCLreq 草稿中说「�Ψ斌w中文而言，Ruby不是�鹘y的排版方式」，加上下面的
范例列举，似乎是用「Ruby」特指了小字号的中外文对照标注？
*Bobby Tung:*
思路大概是�@�拥摹�―
?Ruby Annotation是�⒆⒁簟⑵匆簟⒓倜�等���橥�一件事的技�g��理方式。
?Layout Requirement是���鹘y印刷排版出�l，提供技�g上��理作���⒖肌�
?�鹘y印刷排版，拼音�c注音都是��立的一件事。
?中文���p小�f使用的Ruby，也�c日文�鹘y的振り�⒚�不同，多�橛⒃]�h字、�h字
�]英、�h字�]�h字，所以��立��理。
*梁海：*
#1 讨论简繁两版及日文版的关系
我收到邀请时第一个疑问就是：简繁两版 CLreq 应当如何协调？
我想，不论厂商还是个人开发者还是爱好者（JLreq 对 typography 爱好者来说是
个宝藏，我们经常参考那里面的内容），面对简繁两份 CLreq 都会感到很麻烦。
而且这简繁两份文档注定不会有太多的差异（或许能差个 10�C20%？），甚至和日
文版都会有不少重叠的内容。
在这些大体相同的文档之间把握不同的部分会很痛苦。
中文版合并至日文版近期来看不现实，那么有多少日文版中已存在的内容有必要在
中文 版里重复出现？应当如何协调中日版本之间近似及不同的内容？交叉引用
吗？甚至我们只撰写差异？
如何设定这个内容覆盖范围的限度？「独立可读」？或是「依附于日文版」？
繁体和简体中文版本能否合并？
- 不合并的话，二者如何保持协调？（至少两份文档的主体结构应当平行吧？）如
何向读者强调简繁两版的差异与一致之处？文末提供对照表？
- 合并的话，如何融合并合理呈现双方的内容？（两岸连字体类别（明体 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上的����曾有考量�^�@�c。JLREQ��撰前後�v�r五年，我���@然不��花 上�@
�N久�硖�理。不妨�⒑��w�c繁�w中文排版需求���楫�同��理，也能跟上目前已��提
出CSS����的立即�⒖肌�
文件的���w�c繁�w以及�g�Z的��理可以用�Z表�硖�理。但文字�w系上我��是�A向不
合 �悖�而是先以表格化的方式�碜霾町���理。不然�ξ鞣阶x者�碚f，同�拥募���
在���x�r要於�煞N概念�D�Q，也不易���x。
另附上Hachett Livre的Dave Cramer正在撰��的Latin Requirement作���⒖肌�
http://w3c.github.io/dpub-pagination/
*Chen Yijun (@ethantw):*
我��人�J�椴������@�雍��蔚胤只�繁���~� ��o��是中文原生�~�』蚍��g名�~，有
�r候 即使是在同一��地�^，也��有二至多�N�Q呼，在�@些名�~�]有特定一�N具更
���莸氖褂妙l率�r，若能�x�穹薄⒑�中文地�^皆可接受的、相容或相同 的那一��
��是比�^好的方式。
比如中文字�w的四大分��，在Bobby的文�n中使用了「明、楷、黑、宋」，若能改
用「宋、楷、黑、仿宋」，不�H�p少�崦梁推缌x，也能相容於大��的�~�◇w系，且
後者�Ψ敝惺褂谜��碚f亦不感陌生。
我�K非更偏向���w中文或繁�w中文的其中一�N。我�H是�J�椋�大如W3C�@�拥慕M
��， 其����的����如果能以「���H中文」「易�x中文」�槌霭l�c，求同存��，如
�F在的英文����可以�m用於全英文地�^甚至全世界，中文也�S能有一�N 相容於各
地差��的中立版本的�~�。����^�e只存在於「字形」和「繁��」�@�N不可抗力因
素，那是再好不�^了。
��於各�N具���h的繁���~�。�我�A向於��分�e提出�碛���，��可能�x��*一��*�p方
面 �x者皆可接受的、更好的�~�。��K以附��的方式整理其他的�Z� Ｈ粽娴��o法
相容，再行分化。
��然，�⒖季S基百科和其他���H�M��的文件����方式是�F行�^���H的方式，也�S各
�N方 法我��都能����一下。
--
Best Regards,
Xiaoqian (Cindy) Wu
