W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > May 2011

Re: 俺关于中文layout task force的意见

From: ayhaadam <ayhaadam@gmail.com>
Date: Fri, 27 May 2011 19:56:01 +0800
Message-ID: <BANLkTim8JduhpXQ_YH9ENoSoY-2ajQJyNA@mail.gmail.com>
To: John Hax <johnhax@gmail.com>
Cc: Yuan Chao <yuanchao@gmail.com>, Chris Chen <cwchen@hyweb.com.tw>, Timothy Chien <timdream@gmail.com>, 中文HTML5同樂會ML <public-html-ig-zh@w3.org>
目前的現況是,台灣的字體商習慣把國字跟注音綁定一起來製作字體,如 [1]
也是都有直式、橫式。只不過當然都是版權字體,除非做成圖,不然似乎有點難應用到前端去...

[1] : http://www.dynacw.com.tw/box_pro_05.asp?p_no=6

John Hax <johnhax@gmail.com> 於 2011年5月27日下午7:22 寫道:

> 不支援那就没有意义了。
>
> 用字体的好处是,都不需要Unicode组织预先批准,字体厂商只要做一款这样的字体就好了。因为并不一定需要分配新的code
> point。只要字体厂商加入两个字符替换成另一个字形的部分就可以了。
>
> 有这个需求的,就找一个字体厂商来做就好了。
>
>
>
> 2011/5/27 Yuan Chao <yuanchao@gmail.com>
>
>> 2011/5/27 John Hax <johnhax@gmail.com>
>>
>>>
>>> 如果没有的话,可以考虑向Unicode组织提案增补这些字符。反正CJK这块貌似在增补字符方面还是比较畅通的。个人觉得这是性价比最高的方案。这个可能类似合成字的情况(两个字符自动换成另一个字形,这样就没有语意问题),横排竖排也可以自动处理掉的。
>>>
>> 老實說,個人覺得這個方法當然比讓編排引擎處理簡單的多,
>> 而且效果可能更好。但實際上真正提案要Unicode接受這些合成字符,
>> 然後等到字型商的支援,所需時間恐怕遠比讓layout引擎支援要來的久多。
>>
>> 而且,如同我們正在翻譯的W3C日文排版需求所言,
>> 這裡只是提出我們的需求,並不是尋求解決方案的實作。(是可以齊頭並進的)
>> 這文件也沒有強制性,實作layout engine的軟體商支不支援是他們的自由。
>> 但是個人覺得既然有此需求(尤其是教育市場),就應該列在需求書中。
>>
>> (以下恕刪)
>>
>>
>>
>> 2011/5/27 Yuan Chao <yuanchao@gmail.com>
>>
>>> 2011/5/26 John Hax <johnhax@gmail.com>
>>>
>>>> 看了一下,我之前的理解无误,注音上的声调(除了轻声之外)始终是在某个(最后一个)注音符号之上的固定位置(右上角),并不需要通过ruby解决。
>>>>
>>> 很現實的問題是,Unicode沒有收錄這樣子的字符,網頁內容無法交流。
>>> 同時橫排與豎排的情況也略有不同。
>>>
>>> 像这种固定位置的符号,且组合有限的情况,其实最简单的解决方案是用字体。
>>>>
>>> 話是這麼說沒錯,在排版軟體還沒有支援的情況下,這的確是過去普遍採用的解決方案。
>>> (有所謂的注音字型,每個字符都有配上注音,但破音字得以換字型的方式處理)
>>> 但是要保留語意的話,並不是好方法。而且沒有統一的解決方案。(unicode/html)
>>>
>>>
>>>> 另,我觉得ruby草案里针对注音的处理有点太过复杂,对于实现者来说性价比过低。其实使用Ruby markup未必一定要用特殊的ruby
>>>> css。用inline-block加上直排就可以了。
>>>>
>>> 同樣的問題其實也會出在日文身上,這有待輔助軟體的支援。(自動選擇填入)
>>> 這年頭用vim來刻html的人不多吧?我自己頂多是小修改才這樣子做。
>>>
>>> 更何況,當初提出Ruby的概念進HTML時,就是號稱也可以適用在中文的注音與拼音上。
>>> 現在單單就方便性來否決掉注音,這是過河拆橋啊!
>>>
>>>
>>>
>>>
>>>>
>>>> <ruby>漢<rt>ㄏㄢˋ</rt>字<rt>ㄗˋ </rt></ruby>
>>>>
>>>>
>>>> rt {
>>>>     display: inline-block;
>>>>     font-size: 0.33em;
>>>>     width: 1em; /* 应该设置直排,暂且用width来替代 */
>>>>     vertical-align: middle;
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>> 2011/5/26 Chris Chen <cwchen@hyweb.com.tw>
>>>>
>>>>>   台灣注音符號的標準是教育部的『國語注音符號手冊』(
>>>>> http://www.edu.tw/files/site_content/M0001/juyin/index.htm?open)
>>>>>
>>>>> 聲調位置分 直式 跟 橫式:
>>>>>
>>>>> 直式:http://www.edu.tw/files/site_content/M0001/juyin/images/p131.jpg
>>>>> [image: p131]
>>>>>
>>>>> -輕聲:http://www.edu.tw/files/site_content/M0001/juyin/images/p132.jpg
>>>>> [image: p132]
>>>>>
>>>>> 橫式:http://www.edu.tw/files/site_content/M0001/juyin/images/p221.jpg
>>>>> [image: p221]
>>>>>
>>>>> -輕聲:http://www.edu.tw/files/site_content/M0001/juyin/images/p222.jpg
>>>>> [image: p222]
>>>>>
>>>>> 非輕聲時有 Timothy 提到的 Ruby 中的 Ruby。
>>>>>
>>>>>
>>>>>
>>>>>  *From:* John Hax <johnhax@gmail.com>
>>>>> *Sent:* Thursday, May 26, 2011 2:57 PM
>>>>> *To:* Timothy Chien <timdream@gmail.com>
>>>>> *Cc:* 中文HTML5同樂會ML <public-html-ig-zh@w3.org>
>>>>> *Subject:* Re: 俺关于中文layout task force的意见
>>>>>
>>>>> 关于注音符号的声调位置,能否详细说明一下?按照我粗浅的理解,声调符号是在某个注音符号之上的,本身并不形成独立的flow,所以并没有额外的需求。
>>>>>
>>>>>
>>>>> 2011/5/25 Timothy Chien <timdream@gmail.com>
>>>>>
>>>>>> 1. 有反例,台灣注音符號的聲符位置是一件獨有且需要排版技術處理的事情(Ruby 中的 Ruby?)
>>>>>> 2. 的話台灣也沒有國家標準。既成標準的聯絡人倒是有,至少出版/數位內容在這裡有人 :)
>>>>>>
>>>>>> 2011/5/25 John Hax <johnhax@gmail.com>:
>>>>>>  > 俺的意见比较消极。俺认为没有必要,原因之前其实表达过了。
>>>>>> >
>>>>>> > 1. 已有的日文排版需求已经涵盖了中文排版需求。除了极少数差异(如行首缩进字数不一样),中文排版并没有超出日文排版的特殊需求。
>>>>>> >
>>>>>> > 2.
>>>>>> >
>>>>>> 目前我们缺乏专业排版公司的参与,至少大陆这里是这样。这儿没有方正的人吧。而且我个人对方正不待见。此外与日本不同,大陆似乎并没有排版相关的国家标准。不知对岸可有。
>>>>>> >
>>>>>> > 以上。
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Yuan Chao
>>>
>>
>>
>>
>>
>> --
>> Best regards,
>> Yuan Chao
>>
>
>


-- 
|  ayhaadam@gmail.com  |  Powered by Gmail  |

p222_1_.jpg
(image/jpeg attachment: p222_1_.jpg)

p132_1_.jpg
(image/jpeg attachment: p132_1_.jpg)

p221_1_.jpg
(image/jpeg attachment: p221_1_.jpg)

p131_1_.jpg
(image/jpeg attachment: p131_1_.jpg)

Received on Friday, 27 May 2011 11:56:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:48 UTC