w3c / clreq Goto Github PK
View Code? Open in Web Editor NEWRequirements for Chinese Text Layout
Home Page: https://www.w3.org/International/clreq/
License: Other
Requirements for Chinese Text Layout
Home Page: https://www.w3.org/International/clreq/
License: Other
From Hawkeyes Wind
[[
3.3.2.3.1 中的第一条注解的后半句话变成上角标了
5.1 中的表格加上表格线吧,表头的文本连成一片了
]]
词汇表中新增加了「汉语拼音」一栏。是不是最好加入声调?
we're hopefully quite close to publishing a FPWD of clreq. When we do so, we expect to publish a snapshot of the chinese version of the document in the TR (technical report) space alongside the english FPWD.
to prepare for that, i'd like to work on various aspects of the markup of the zh doc. If i don't hear any objections in the next couple of days, i'll begin making these changes.
[1] i'd like to migrate the document to respec. This is a javascript framework used widely at the W3C, which makes it much easier to create documents. For example, it automatically generates much boilerplate text and the toc, etc. It also makes it easier to provide the needed metadata, and produces an output document that is easier to get through the publication requirements.
Robin Berjon has, today, implemented a localization of respec for Simplified Chinese. You can see a very quick and dirty example of it at http://www.w3.org/International/docs/chinese-layout/zh-respec/index.html (ignore the double numbering, missing images, etc. – i propose to clean up that stuff when porting to the respec framework). We may need to tweak some of the boilerplate text. (Thanks to Xiaoqian for the initial translation.)
[2] i'd like to add more ids as anchors. For example, i tried pointing someone today to the information about characters used for quotations in Chinese, and had to say "point 2.1 under http://w3c.github.io/clreq/#categories_and_usage_of_punctuation_marks", rather than being able to link closer to it.
[3] i'd like to flatten out some of the nested lists, making h5 into real headers (which will help with the ids, as well as improving the semantics of the document) and make h6 into span class=leadin. This will also help reduce some of the complexity for editing (i already fixed a couple of errors that were confusing my editor, but there are some more, and i'm struggling to find where exactly the markup is broken).
[4] i plan to implement the changes to the way unicode characters are referred to, per the separate issue.
[5] i'd like to implement some of the inline and other markup and styling conventions described at http://www.w3.org/International/docs/styleguide (modified, as necessary, for Chinese).
any objections?
Move this directory outside zh/ so that the English/Chinese versions can share the images
今天在很特殊的情况下,知道了W3C发布了《中文排版规范》!作为一枚码农,好奇的查看了W3C的源代码。不过第一眼我就看到个问题,列表用的都是ul,规范里说的ol呢,dl呢?你tm是闹哪样啊?我亲爱的W3C君.......
http://w3c.github.io/clreq/#characters_used_in_chinese_composition
http://w3c.github.io/clreq/zh/#characters_used_in_chinese_composition
the heading of section 2.1.1 is the same as that for section 2.1. Should we simply remove the heading (and section tags) for this section? (ie. section 2.1.2 would become the new 2.1.1)
相关段落为:3.1.1.b > 引號 > 注2
繁體中文也有使用彎引號者,但鮮少用於直排。
http://w3c.github.io/clreq/#basic_principles_for_development_of_this_document
in the zh version, section 1.2 has just three bullet points.
http://w3c.github.io/clreq/zh/#basic_principles_for_development_of_this_document
in hackpad there was text for another set of bullet points (which i include below for reference).
should clreq include these additional bullet points or not? (they are already in the en version, so the question is whether to delete from the en version or add to the zh version).
This document mainly adopts the following policies to explain the features of Chinese composition:
It does not fully cover all details of the Chinese composition system, but mainly describes the differences from Western composition systems.
It explains in detail the similarities and differences between traditional and Simplified Chinese composition.
It describes features of Chinese composition that differ from those mentioned in Requirements for Japanese Text Layout.
It describes presentational results and considers these results as issues and requirements for Chinese text layout. Meanwhile, it offers principles or methods for for handling these issues, without describing particular technological solutions.
It suggests solutions for, or explains, present-day issues that people face in Chinese composition.
It provides typical instances of Chinese composition and their actual use cases as much as possible.
In consideration of non-Chinese readers of this document, figures are used for explanation wherever possible.
It mainly explains modern Chinese publications. Looking back to the publications in the time of movable type, there may be some differences, but they are still considered part of Chinese composition. The document does not yet fully cover ancient books. Future editions may be revised with such features in mind.
For non-Chinese readers, frequency of use is indicated for each requirement. These frequencies are not the outcome of any accurate research, but arise from the long experience of the authors. Non-Chinese readers should understand that they are intuitive for ordinary Chinese readers. These frequencies provide only rough information to prioritize the importance of issues.
The main target of this document is common books. Other publications, such as magazines or newspapers, are also included.
最近看到各位专家有关中文版式的讨论,很受启发。
只是需要补充的是中文版式里面似乎没有考虑到像蒙古文这样连写文字的禁则等问题:
如,以中文为主的版式是横向的,且其换行、断行都有其基本成熟的规则。但如果其中加入蒙古文(其实阿拉伯文也同样),
其行内就出现新的问题。所以我觉得我们还必须考虑中文版面多文种混排的问题。
我不知道各位专家是否已有成熟的方案。
結束雙彎引號[”](RIGHT SINGLE QUOTATION MARK) 英文翻译是否应该(RIGHT DOUBLE QUOTATION MARK)?
In the document we use Hanzi for the translation of 漢字 at the time. Richard suggests we replace it with Han characters. Will edit it if no comments advise otherwise.
目前查到的很多翻译直接使用的 traditional chinese, 但是无法和繁体中文相区别。如果突出传承字的特点。Inherited traditional character是否妥当?行业内是否有标准的译法可供参考?
内核恐慌第十六期提到,大家对本文档有相当严重的误解。与其反复澄清本文档不是一份 Spec,还不如直接在开头声明:本文档只为某些特定的人群提供参考,其他人并无必要将其奉为圭臬。
之前的观察,W3C的草案文档似乎每次更新的时候都会同时更新最顶上的日期,但CLReq草案的日期自首次公开发布以后似乎就没有更新过,至今仍是四月十日。看GitHub最后一次修改是五月一日了吧。
希望能够及时更新该日期,以方便草案读者知晓文档是否有新版本。
在整个文档中,我们没有看到“图文混排”的描述(如:四周型环绕、上下型环绕),不知这个文档中是否仅是对文字显示排版的需求,不涉及到其他元素?
按照GB/T15834-2011中,5.2.1的規範:
句號、問號、嘆號、頓號、分號與冒號均置於相應文字之下偏右。
這部分也反映於UTR#50的範例上。
關於這一點,的確於大陸繁體古籍竪排書上如此處理,使得這一點規定不是「簡繁」標點符號的差異,而是「地區排版習慣與規則」的不同。建議於下一版在3.2標點符號與其排版中加一節做詳細的說明。
這會與Locale(zh-Hant-CN, zh-Hant-TW, zh-Hant-HK),以及Unicode及字型實作有所影響,需要詳細說明。
from @ethantw
[[
「5.1 附錄A 中文標點符號表」有個欄位的標題是:
直排時旋轉90度(是∕否)
原先的描述過於「橫排本位」,我希望改成「依文字書寫方向標注」(依文字書寫方向使用相應的標注方向)。
]]
from Xidorn
[[
3.1.1.2
]]
from @ethantw
[[
Re 省略号
這部分在「3.1.2 標點符號的字形、尺寸與字面分布」節中已經有說明。因為國標跟台灣教育部的省略號都位正中,所以並沒有特別描述。
包括:刪節號、破折號等標號,位字面正中,佔一個漢字之高、二個漢字之寬,並不得以適配分行之由拆至二行,依文字書寫方向使用相應的標注方向。
有些漢字字體會把U+2026的點放在底部,主要應該是因為這個字元漢字、西文共用,放底部方便fallback。
Re 连接号
那分文件採用的Unicode字元很亂,基本上是字形的差異,語意上還是用en dash才對。(GB/T是推薦而非強制標準,所以模糊、有問題的地方就不去管它了)
Re 书名号
乙式書名號看來還是要區別大陸跟台灣的用法(原先沒寫是不希望太複雜,光書名號就有甲、乙式,乙式又分二種……)。
台灣是以單書名號為篇名、雙書名號為書名,比如《舊約聖經》和〈馬太福音〉。
]]
括号类符号()「」‘ ’ 等都是一对,对于单独的名称,各处有各自称谓,现在文中混杂,是否需要统一?
Unicode 的字符名称已经固定为 LEFT RIGHT,已经无法修改,只能引用
如 GB 的叙述使用「前后」而不用「左右上下」因为要照顾到横排和竖排,如( 是「前括号」,” 是「后双引号」
而《重訂標點符號手冊》(2008年修訂版)的行文中既用「前后」,也有「下引号」的叙述
现在草案中还使用「开始」「结束」,略显繁琐。
建议:
From 殷建民老师
[[ ..
文中多次出现用日文排版规则来解释中文排版的内容,尽管我们都清楚,中文版式需求是根据日文版式需求文档修改的,但没必要去类比日文。例如,1.2中第3条 “中文排版與日文排版有近似之處,也因書寫系統不同,而有所差異”。将此条单列,作为中文排版的一项特色来说明,有点突兀。况且读者也不一定懂日文的排版规则,建议修改相关内容。
..
]]
+1 from me
现在的版本中关于引号写的是
引號用於強調字詞,或作為引用話語、文獻的起訖邊界。
引号还可以直接用于表示话语本身,例如小说中的对白。这个感觉应该不属于“引用”的范畴。
“行间注是标注于字词旁侧的小字号补充文本。行间注的注文通常位于行间,与其所标注的基文对齐,因這一性質而又名為行間注。行间注在中文排版里的用途主要为标音与释义。”
行間注是標註於字詞旁側的小字號補充文本。行間注的注文通常位於行間,與其所標註的基文對齊,因這一性質而又名為行間注。行間注在中文排版裡的用途主要為標音與釋義。
用简体字的人群数量在这搁着,如果真想中文技术、出版社区参与进来的的话,不出个简体版就会有这种问题喽。
我在轻小说译本中有看到过类似于
“一段话。
“第二段话。
“最后一段话。”
这种形式的不匹配的引号用法,或许值得特殊说明?
http://www.w3.org/International/docs/chinese-layout/zh/#generatedID-88
文档里的「foot」是不是应该作为单个词汇出现?「(prosody)」只是作解释作用,参照:
3.1.5.a 所述「两个省略号连用时,占四个漢字位置并须单独占一行」,援引《GB/T 15834—2011》。
这条规则得以成立的前提是,省略号的使用者须严格遵循《GB/T 15834》所定义的标号使用规范。该「规范」定义了「十二连点」所标示的是「诗行、段落的省略」。
在通用实践里,「两个省略号连用」完全有可能出现在「行内」;因此《GB/T 15834》所规定的书写形式,似乎不宜列入通用排版需求的「分离禁则」。
2.2节中的字体范例图像,所展示的字体不知道是以何种标准选择的(也许是直接从系统或软件预装字体中选取而来)。个人感觉效果不佳。在此提出一些看法,见笑。
个人认为字体范例的选取应使用较常见于印刷品中的字体。并且基于可能的“预装字体优先”的选择。我的建议如下(皆为简体中文范例的选择):
(括号内为其它备选项,标注等号的字体名为与推荐选项中文字形相同但文件不同的字体)
宋体:
宋体-简 粗体或常规体(中易宋体,=华文中宋,方正书宋)——基于铅字宋二体的字体
方正宋体-超大字符集(=方正宋体)——基于铅字宋一体的字体
黑体:
黑体-简 中等(=华文黑体,=Adobe黑体,方正黑体)——基于铅字黑体的字体
微软雅黑(=方正兰亭黑)——大字面的现代黑体
思源黑体——字面介于前二者之间的黑体
楷体与仿宋体由于现有字体的字形高度一致,不作推荐。
另外:
字体范例字体似乎都经过了电脑加粗,不利于展示字体,望修正。
个人不太喜欢**教育部标准字形,建议使用旧字形的字体来展示繁体中文。
以上,不当之处请指正。
@lianghai 提到,當前的中文標題「中文排版規範」可能使讀者誤會文件的本來目的。英文標題是「Requirements for Chinese Text Layout」,直譯過來應作「中文排版需求」。而JLReq的日文標題是日本語組版処理の要件,其中「要件」也表示「需求」之意。希望正式名稱改為「中文排版需求」。
the zh doc often uses <h5> markup around text inside <li> markup. This is problematic wrt sectioning, and causes some problems for respec, and i don't think it's really semantically sensible.
i recommend that we replace that markup with <span class="leadin"> and move it inside the following <p> tag.
This actually makes the English version easier to read, although i suspect that there is a small difference in expectations of layout between English and Chinese versions.
i'm making this issue now so that i don't forget to. If you wait a short while, i'll put up the latest english translation, which will show what i suggest. I'll add a comment to this issue when it's ready.
from @miemie
[[
許多理工書籍、科技文獻、西文教科书语法书籍等內含大量西文詞句、並採用橫排,為求標點符號體例一致,也有採用
[.](FULL STOP)
為句號、採[,](COMMA)
為逗號與頓號的案例。詳見3.1.3節。
上文与 3.1.3 描述科技文献句号时所指涉的字符不一致,后者所用的 [.](FULLWIDTH FULL STOP)
应该更值得推荐。另外,与 FULLWIDTH FULL STOP
搭配使用的逗号应该推荐 FULLWIDTH COMMA (U+FF0C)
,不必转为 COMMA (U+002C)
。
补充:3.2.1 末尾也有提及科技文献的句号,问题同上。
中文版还是写中文名吧:权循真
英文版再写Xidorn Quan就好了
如:3.2 標點符號與其排版
本節主要基於中國大陸的《標點符號用法》(GB/T 15834–2011)及台灣教育部的《重訂標點符號手冊》(2008年修訂版)。前者屬推薦標準,後者主要用於規範教科書等教育書籍,對一般出版品不具強制性。
兩份參考文獻、以及其他的文獻另建於附錄C,僅列文件名與代表編號。盡量讓「中國大陸」、「台灣教育部」等不出現於內文中。
3.1.1.2 括号
在简体中文中括号的类型似乎还是比较丰富的,GB/T 15834-2011 里面除了圆括号以外还列举了方括号([])、六角括号(〔〕)、方头括号(【】)三种。见该标准 4.9.3.2-4.9.3.5。或许应该考虑添加进去。
直排時,順其行文結束,各欄左右行數可以不一致。
此处「各欄左右行數」似乎是 typo?根据上文推断,是否应为「上下各欄行數」?
橫排時,各欄的行數需平均。但因字數不足,行數無法與欄數配合時,不足的行數於最後一欄末尾留空。
就大陆地区的横排实践而言,「平均各栏行数」应该仅是某一种特定的排版偏好(optional),似乎不足以构成普遍的排版惯例(conventional)。
平均各栏行数的目的,是保证各栏的「视觉长度」尽可能一致。
因此,平均各栏行数通常有一个设计前提是段落密排,也即没有额外段间距;否则,以「行数」为基准来实现平均计算,通常难以得到理想的视觉平均效果。当下中文排版实践中,段间距已获得普遍应用(甚至有不少设计者在段首缩进的同时,叠加使用段间距)。
此处是否值得加注一笔?
不知这是否构成问题。举两个例子:
似乎还有很多。
“示亡号”就是在人名旁边加一圈黑框表示这个人已经死了的那个符号。这个符号似乎在各种标准里面都没有出现,但是在正规档案和书籍中似乎并不鲜见。
维基百科相关资料:https://zh.wikipedia.org/wiki/%E7%A4%BA%E4%BA%A1%E5%8F%B7
本文档还处于草稿阶段,为方便编辑们的协作,暂时还是简繁体混合整理。
第一版正式草稿完成后,将进行繁体版和简体版的转化(保留两者独有的需求规范),并在文档里提供繁体版、简体版和英文版的链接。
欢迎大家在任何阶段提交简体版和繁体版部分转化的pull request。
還有一個與樣式較無關的問題,目前的注釋id自原始頁面由腳本自動生成,後加入的內容已打亂其id排序,也沒有對注釋加入閱讀編號,引用時會比較麻煩。
在“版心”设计元素中,是否还可以补充一个“字间距”,它的用途是让用户设置“每行允许显示的字数”?
in text such as the following:
句號[。](IDEOGRAPHIC FULL STOP)、逗號[,](FULLWIDTH COMMA)以及頓號[、](IDEOGRAPHIC COMMA)。句號表示語句結束、逗點表示語氣停頓、頓號使用於並列連用、表示次序的字詞之間。
the Unicode code point values are not listed.
I suggest that we change the above, and similar text, to read:
句號[。](U+3002 IDEOGRAPHIC FULL STOP)、逗號[,](U+FF0C FULLWIDTH COMMA)以及頓號[、](U+3001 IDEOGRAPHIC COMMA)。句號表示語句結束、逗點表示語氣停頓、頓號使用於並列連用、表示次序的字詞之間。
理论上大多数文档的初期都应该是使用行内注解的方式来管理 issue 的?那种情况下通常使用邮件列表来接受反馈。因为本文档应当需要接受中文用户的反馈,因此如果使用邮件列表的话,应该写明一个使用中文的邮件列表,比如 public-zhreq 等,而不是写英文的 public-i18n-cjk。
另外考虑到邮件列表的使用在中文用户群或许不是很广泛,或许也可以考虑将此 GitHub 或者甚至相应的 Hackpad 链接写入文档。我不是很确定 W3C 在这方面的规定。不过或许使用邮件列表管理而不是 GitHub 仍然是一种合适的方式。
From Xidorn
[[
[1] https://zh.wikipedia.org/wiki/%E6%A0%87%E9%9F%B3
]]
From Bobby
[[
這份文件中盡量減少使用Ruby,我把各點列出來
From Xidorn
[[
我的想法是“行间注”保留 interlinear annotation 即可,因为根据文中对行间注的解释,至少最后一条用作批注看过去与日文中的 ruby 在含义和用法上都有较大差别。
“注文”可以考虑使用 annotation text 来代替 ruby text。
]]
在 4.1.2、4.1.3 和 4.1.5 中有几处写了“注1)”、“注2)”等。我想这个或许应该按照其他的一样写为 Note。
3.1.4 行首行尾禁則Prohibition Rules for Line Start and Line End
為了保持閱讀順暢、體例一致,多數標點符號的位置有其限制,通常一個標點符號依其性質,禁止出現在一行之首或之末。
---- 标点不能出现在行首是通用做法。希望确认一下,标点符号是否不可以出现在行尾。
目前草稿內的標點並不包括問嘆號「⁈」(U+2048)和嘆問號「⁉」(U+2049),依據兩岸三地敎育部門的規範,這兩個也不是正式標點。但在日常生活、文案、排版中,尤其在一些流行文本裏,的確會使用到這兩個標點符號。因此建議加入這兩個標點,其規則與雙問號「⁇」(U+2047)相同。
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.