W3C home > Mailing lists > Public > public-html-ig-zh@w3.org > September 2010

Re: 現有中文的避頭點禁則改良芻議

From: Jedi <jedilin@gmail.com>
Date: Fri, 10 Sep 2010 15:42:43 +0800
Message-ID: <AANLkTinNgDWAi7nJ4nNFq3s2M2KBcLvhOnCff0LXK9WU@mail.gmail.com>
To: public-html-ig-zh@w3.org
看到自己的錯字,真糗。可讀性是 readability 纔對。

Best,
/Jedi/

2010/9/10 Jedi <jedilin@gmail.com>:
> 我剛剛跑去圖書館翻出舊報紙拍了圖,所以來補充這個已經有點時間的討論串。
>
> 我 2010/08/31 的時候,剛好看到了聯合報內附的 New York Times,
> 我猜測這個 New York Times 是聯合報自己排版過的,因為有幾版是中文翻譯,
> 表示就算是英文部分的版面,仍可能跟原始的 New York Times 不同,
> 因為我附近沒有紙本的 New York Times 可以看,
> 所以無法確認在美國發行的 New York Times 是否也是如此。
>
> 首先來看看第三版,有一篇「As Media Evolve, Change Speeds Up」的報導內容[1]
> 第三版的內文雖然沒有 justify,但是大概是為了要能擠進字多的內容,所以字間距離卻很窄,
> 我乍看之下以為出現了一個叫做「aniPad」的新產品(可能是以「動漫」為主題的平板電腦)
>
> 如果要把這個不良的結果設想在中文情境當中,可能會是讓人把「車侖」看成「輪」這樣的情況。
>
> 再來看看第十二版的「Beyond Spock, Nimoy Finds Art Photography」的報導內容[2]
> 雖然是同一份報紙在同一天的內容,第十二版的文字卻都 justify 了。
> 在這一段報導當中,短短的幾行就一口氣出現了
> 字間距離拉寬、字母距離拉寬、字詞截斷(分作兩行,用連字號連)的情況,
> 而且字母距離拉寬會拉到跟字間距離一樣寬的程度。
> 我在這個地方反覆多看了幾遍(其實就是視線多停留了幾百毫秒,之類的),
> 才知道這是在講麻州。
>
> 不管是第三版的壓縮,或者是第十二版的拉寬,說實話,對我的閱讀都造成了困擾,
> 而且這些的確也都是 accessibility 的問題(同時也是 readibility 的問題)
>
> [1]: http://dl.dropbox.com/u/784910/htmligzh/DSCF0216-20.png
> [2]: http://dl.dropbox.com/u/784910/htmligzh/DSCF0211-15.png
>
> /Jedi/
>
> 2010/8/28 Jedi <jedilin@gmail.com>:
>> 分別回答一下:
>>
>> 1. WCAG 2.0「已經」是一項 W3C 標準了,這不是 HTML 標準,
>> 而是網頁內容親和力標準。
>>
>> 至於 W3C 各項標準之間的「位置關係」,我很久前有畫過一張概念圖可以參考[1],
>> WCAG 在「存取」那邊(後來我都用「取用」這樣的說法),
>> HTML 則在「結構」那邊。
>>
>> 2. 主要是因為會造成類似這樣的排版結果,所以應避免:
>>
>> 第一列有好多好多好多好多字
>> 第二列也有好多好多好多好多
>> 第     三     列
>> 這  樣  很  難  讀
>>
>> 3. 這是在說如果設計網頁的人指定了內容左右全齊的時候,
>> 必須要讓讀者能夠把內容重新設回僅齊左或僅齊右的選項,
>> 不是在說「HTML 標準必須要提供一個機制……」
>>
>> 4. 參考 2.,紙媒很多狀況跟網頁很不一樣。
>>
>> 另外,在 WCAG 2.0 裡面有註明這裡的「全齊」指的是「左右」,
>> 也就是橫書的情況,並沒有特別提到直書也不可以齊頭尾。
>>
>> [1]: http://Jedi.org/slide/image/web.chart.in.6-full.png
>>
>> Best,
>> /Jedi/
>>
>> 2010/8/28 oldcat <blog.oc@gmail.com>:
>>> (齊頭尾可以同時適用直排與橫排,左右全齊只能適用橫排,所以我
>>> 通常使用齊頭尾。:))
>>>
>>> 回到 Jedi 提示的文件,我有幾個疑問:
>>>
>>> 一、那個文件是什麼位置?未來會成為 html 標準?
>>>
>>> 二、我不曉得反對齊頭尾的論據是什麼?是因為現有齊頭尾設計不良,
>>> 還是齊頭尾本身就不良?
>>>
>>> 我們應該改良齊頭尾,還是乾脆封殺齊頭尾?
>>>
>>> 三、齊頭尾事實上是現存的標準(選項之一),所以並不存在要不要
>>> 提供「不要齊頭尾」的機制,因為我的提議只是尋找改良的方法,並
>>> 不是「只准齊頭尾,其他對齊選項全部取消」。
>>>
>>> 四、不曉得有沒有人能解釋為什麼紙媒幾乎全部齊頭尾,卻沒有人說
>>> 那樣妨害 accessibility ?
>>>
>>> oc
>>>
>>>
>>>
>>> 2010/8/28 Jedi <jedilin@gmail.com>
>>>>
>>>> FYI:
>>>>
>>>> 在 W3C WCAG 2.0 當中,齊頭尾(左右全齊 / justified)被視為有害 accessibility [1][2]
>>>> 如果真的要齊頭尾,則必須要提供能夠「不要齊頭尾」的機制 [3]
>>>>
>>>> [1]:
>>>> http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-visual-presentation
>>>> [2]: http://www.w3.org/TR/WCAG-TECHS/C19.html
>>>> [3]: http://www.w3.org/TR/WCAG-TECHS/G172.html
>>>>
>>>> Best,
>>>> /Jedi/
>>>>
>>>> 2010/8/28 oldcat <blog.oc@gmail.com>:
>>>> > 2010/8/28 John Hax <johnhax@gmail.com>
>>>> >>
>>>> >>
>>>> >>
>>>> >> 大陆正式出版物用标点悬挂的,我是没有见到过,普遍用的还是标点压缩和字间距调整。我个人认为标点悬挂只是活字印刷阶段的过渡产物,当然这是我的推理,没有足够的证据,呵呵。
>>>> >
>>>> > 台灣也沒有用行尾凸排,所以我很訝異日文竟然有。
>>>> >
>>>> > 是不是活版印刷留下來的「遺跡」,我猜應該也是很有可能,只不過
>>>> > 這個遺跡想要解決的問題(避頭點),現在在中文網頁上只剩下「從
>>>> > 本行行尾拉掉一個字,補到次行去」這種解法,而 Hax 提到的標點壓
>>>> > 縮和字間調整這兩種解法卻消失了……唔,好吧,在設定齊頭尾的時
>>>> > 候,我們可以有字間拉散,但卻沒有字間壓縮可以選擇。
>>>> >
>>>> > 現在的解法造成網頁和傳統紙媒的排版中間有一個巨大的落差,那就
>>>> > 是極少中文網頁會使用「齊頭尾」排版。
>>>> >
>>>> > 我們看見現在大部分網頁都是齊左。偏偏如果我們對比起紙張媒體的
>>>> > 排版方式,會訝異地發現情況完全相反,絕大部分紙媒,圖書、雜誌、
>>>> > 報紙,99.9%內文都是採用齊頭尾排版的。
>>>> >
>>>> > 不只中文如此,傳統的日文書報,絕大部分也是採用齊頭尾編排。
>>>> >
>>>> > 為什麼紙書會採用齊頭尾,而網頁卻不會呢?我覺得避頭點和方塊字
>>>> > 字元對齊的解決方案不良,是最重要的原因。
>>>> >
>>>> > 所以我希望能討論如何改良這些問題。
>>>> >
>>>> > oc
>>>> >
>>>> >
>>>> >>
>>>> >> 2010/8/28 Yuan Chao <yuanchao@gmail.com>
>>>> >>>
>>>> >>> 2010/8/27 oldcat <blog.oc@gmail.com>:
>>>> >>> > 2010/8/27 劭非程 <csf178@gmail.com>
>>>> >>>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> 如果你把版芯看作desiredWidth,当然悬挂是可行的,但是很多时候版芯其实属于maxWidth,超出版芯可能显示异常,这种时候就不可能悬挂处理标点了。按我的理解,HTML的排版范围恰恰是把宽度看成maxWidth
>>>> >>> 第一次看到日文規格中把標點放到max width外真的很奇怪,很好奇中文排版界普遍的作法是?
>>>> >>> --
>>>> >>> Best regards,
>>>> >>> Yuan Chao
>>>> >>
>>>> >
>>>> >
>>>
>>>
>>
>
Received on Friday, 10 September 2010 07:43:31 UTC

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