- From: Xidorn Quan <quanxunzhen@gmail.com>
- Date: Thu, 9 Oct 2014 22:19:21 +1100
- To: Bobby Tung <bobbytung@wanderer.tw>
- Cc: "Hu, Chunming" <hucm@w3.org>, Angel Li <angel@w3.org>, public-zhreq@w3.org, 李松峰 <lisf@turingbook.com>, Xiaoqian Cindy Wu <xiaoqian@w3.org>, 中文HTML5同樂會ML <public-html-ig-zh@w3.org>
- Message-ID: <CAMdq6987s7Q1FNeP4Mw3r4NKtqA8KqbZ3SjsEu5yOkY0f=FOxg@mail.gmail.com>
可以把不同系统下相应的楷体字体名列一下吗?如果能把繁简中和日文分别列出来就最好了 2014-10-09 21:37 GMT+11:00 Bobby Tung <bobbytung@wanderer.tw>: > 補充幾點技術上的細節: > > 希望達成的幾項大原則: > > 一、中文漢字基本上不會以斜體(italic、oblique)呈現; > 二、盡可能地希望以Serif、Sans-serif、Cursive等Generic-family指定中文字體如宋、黑、楷,以達到基本的互通。 > > 現在大致有兩項問題: > > 第一,是CSS Font module level 3 [1] 的說明 > > 這裏將中文楷體與宋體放在serif,而將行書、草書歸於cursive,為了滿足前面兩項大原則,應該修正為: > > i: 楷體放到Cursive下頭; > ii: 當該字形沒有自帶italic時,就不該以強制轉斜的oblique呈現 > > 這是迅速能符合規範的作法。現在除了Firefox以外的瀏覽器,也都會直接將cursive制定為Win/Mac兩方都有的標楷體。 > > 第二,italic的定義 > > italic在英文字體裡定義為手寫體,理當對應到我們的楷體;在日本也認為italic應該對應到他們所稱的宋朝體,也就是我們的仿宋。 > > 除此之外,還有個問題是中文OpenType字體裡頭就算有著多種字重,也不會像英文字體一般自動選擇到對應的字重上頭。 > > 目前的@Font-face如果能夠擴增,除指定標準字外,希望能夠有新的結構來指定該字體在粗體時使用哪一個字型、italic時使用哪一個字型。 > > 這也能滿足上述兩個大原則。 > > > [1]: http://www.w3.org/TR/css3-fonts/#generic-font-families > > > WANDERER Digital Publishing Inc. > Bobby Tung > Mobile:+886-975068558 > bobbytung@wanderer.tw > Web:http://wanderer.tw > > Hu, Chunming <hucm@w3.org> 於 2014年10月9日 上午10:25 寫道: > > 你可以在中文网站找到相关内容: > http://www.chinaw3c.org/issue-chinese-fonts.html > > *From:* Angel Li [mailto:angel@w3.org <angel@w3.org>] > *Sent:* Thursday, October 09, 2014 10:03 AM > *To:* public-zhreq@w3.org > *Cc:* 李松峰; 'Bobby Tung'; hucm@w3.org; Xiaoqian Cindy Wu > *Subject:* 【W3C问题讨论】CSS中文字体问题 > > 中文呈现邮件列表各位同仁, > > 大家好! > > 在9月11日研讨会上,几位数字出版的工程师提出一个在实践发现中的CSS中文字体问题,我们把问题提交到国际化工作组[1],下面对近期工作的总结, > 期待各位进一步的意见和建议! > > *问题描述*: > > 中文的7-8种主要字体(宋,黑,仿宋,楷体,幼圆,雅黑等等),不能很好地匹配(对应到)CSS3字体标准[2] 所定义的五类通 用字体generic > font families里面(serif,sans-serif,cursive,fantasy,monospace)。并且,中文字库很大,用 > WebFont > 等方式下载一个字体太耗费网络资源。大部分开发者希望能直接使用系统自带的字体,在没法获取这五类通用字体的情况下,自动从系统已有的字体里面寻找最接近的字体; > > *可能的解决方案:* > 1. 扩展现有的五类通用字体来对应定义中文字体,如尽可能重用对应到现有的通用字体名字里面; > 2. 定义一系列全新的通用字体,涵括所需要的中文字体; > 3. 定义一个中文字体的注册器,来定义字体如何匹配,让开发者来定义中文字体如何对应到五类通用字体; > 4. 自动分类用户系统已有的字体,通过分析和对比字体的相似度,把他们匹配到五类通用字体; > 5. 优先匹配用户友好度高的字体,如对serif,优先匹配到用户更习惯的宋体; > > *期待听到大家关于以下几个具体问题的看法:* > 1. 在数字阅读的内容制作中,需求比较大的字体有哪些? > 2. 对上面的问题描述有什么补充吗?或者有别的这方面的类似问题吗? > 3. 觉得上面的几种解决方案哪个比较合适? > > *感谢以下专家们的意见:* > > 李松峰老师:关于中文字体与CSS3通用字体匹配的问题,我认为这个标准给出的对应关系还是合适的: > > 黑体对应sans-serif(无衬线) > 宋体对应serif(衬线) > 楷体、仿宋对应cursive(手写体) > 美术字体对应fantasy > monospace是等宽字体——汉字都是等宽的,所以只适用于西方字体 > > 关于中文字库大的问题,似乎也没有那么严重。一是字体变化比较频繁的往往是标题,而标题字数有限,在WebFont中仅嵌入那些标题用到的字 > 符,可以大大减小字库文件体积。二是上网速度越来越快,成本也会逐渐降低,如果必要的话,就算为显示正文下载一款几MB的字库,也不是什么大 > 负担,实在不行也可以考虑只嵌入正文中用到的字符。 > > 数字阅读取决于屏幕分辨率,如果屏幕分辨率足够,辨识度高的宋体、楷体、仿宋和英文衬线字体还是首选;如果屏幕分辨率不够,可以考虑一些等线 > 体,如细黑、雅黑、准圆等。 > > Bobby Tung: > 目前較急需處理的問題在於Serif的陳述裡把中文楷體也納入,但放在Cursive較為適當。(更详细的意见请见 > http://lists.w3.org/Archives/Public/public-html-ig-zh/2014Oct /0000.html) > > 陈奕钧: > 繁簡的主要印刷體一致,都是「黑、宋(=明)、楷、仿宋」; > sans-serif = 黑體,serif = 宋體,cursive = 楷體或仿宋體,fantasy => 沒有定論。 > 之前興趣小組大家討論过,cursive該不該對應到楷體,因為在西文中,cursive是比較潦草的手寫體。 > 中文印刷裡,楷體(或仿宋)常用來代替西文的意大利體(斜體,italic)的概念。 > 排版規範應該不太適合這樣定義,我們只是把概念很類似的東西拿過來用而已。Mac OS X和Windows上的確是「sans-serif = 黑體」「serif > = 宋體」,cursive因為還沒有共識,還沒有瀏覽器敢動它。 > 但是CSS spec應該可以說,中文裡sans-serif就應該對應黑體。 > 現代瀏覽器通常就是認最後面的generics font families來決定要用什麼字體來顯示無法map到字體的字元。 > > 张磊: > 如果我又想用英文衬线字体,也想用宋体时,还是区别开比较灵活。希望能为中文新引入generic font family,比如按宋芳楷黑加4 种名字。 > > 黄海平: > 楷体,宋体,兰亭黑,兰亭中黑需求较大。 > 我们目前字体不存在的时候用系统字体。 > 第2,3,4种解决方案都比较合适。 > > [1] https://www.w3.org/International/wiki/Chinese_font_families > [2] http://www.w3.org/TR/css3-fonts/#generic-font-families > *感谢小倩整理并汇总以上专家意见!* > > > 安琪 > > --------------------------------------------------------------------------------------------------- > Angel Li > W3C/Beihang Site Manager > Room G1121, New Main Building, Beihang University > No. 37 Xueyuan Road, Beijing, China > Phone: 86-10-82316341 > Mobile:86-13810176889 > > --------------------------------------------------------------------------------------------------- > > >
Received on Thursday, 9 October 2014 11:20:34 UTC