(wrong string) 間隔

分词完全是一个技术问题,而不是一个用户心理的问题,作为一个偶尔杂用英文单词的中国人,没有必要去为了迎合英文的分词断行问题而手动插入空格。

中文引入外文并不打破中文习惯,因为语言有外来语是很正常的。杂有外来语,和真正的双语写作,是两种截然不同的情况。所以被引用的外来语仍然遵循的是中文的排版习惯。

排版效果那是排版软件或office软件的问题,不是用户的问题。

早年,为了所谓“调和”和“兼容”,还有把中文每个字后面都插一个空格的情况。显然这个不能忍,所以就被淘汰了。

设置专门字体也是软件的问题。现在新的CSS草案已经允许指定虚拟字体,即特定range里用某种字体。

至于说排版效果,插空格的效果其实并不好。因为空格通常是1/3em,某些字体是1/4em,比如文泉驿微米黑。但是实际排版中,对于单个单词,其实间隔小到1/6em才好看。

2010/10/2 梁海 <lianghai@gmail.com>

> > 在中文为主的混排文本里,首先我们遵循的是中文用户的习惯。
>
>
> 当然,当然要首先遵循“中文用户的习惯”。但实际上在中文文本中引入外文就必然打破了中文的固有习惯(至少汉语里原本就没有外文);也必然要一定程度地引入外文地排版习惯(比如在引入的外文文本内部遵循原文的排版习惯);同时,为了最佳的混合排版效果,我们需要做一些“调和”与“兼容",比如有时我们为外文指定一个专有字体的同时,甚至还会调整外文的字号到比中文字号稍大(比如
> 1.1 甚至 1.2 em)。
> 为了达到尽量优美的排版效果,在中外文的交界处使用尽量兼容两方习惯的排版方式(比如增大间距或插入空格),是非常有逻辑而且效果更优的。
>
> > 对于大多数情况,中文里混合的只是一两个单词,尤其是缩写词,因此手动插入空格是额外的负担(例子:中文HTML同乐会)。
>
> 这个就因人而异了,我不觉得两个有理有据的空格会是什么额外的负担。但对于从来无此习惯的用户来说,如果无法理解原因,确实会觉得多此一举。
>
> > 所以我认为手动插入空格只是排版软件本身的不足而引发的一个不怎么好的解决方案。
>
> “手动插入空格”在纯文本以及很多文本编辑状态下是唯一的解决方案(目前几乎只有 office 类软件和专业排版工具如 InDesign
> 之类才支持中外文之间的自动距离调整),并且我前面论述过了,这个方案没什么不好的,只有不足:那就是和基于 <span lang="xx">
> 的方案比起来没法交代那么详细的语义信息。
>
> > 再举一个例子,当你在中文里引用一段英文时,如“HTML5 Working
> Group”,在英文与引号之间是否要插入空格呢?这里的问题是,引号是通用的。
>
> 首先,引号不一定是通用的。
>
> 大陆的简体中文标点符号标准里似乎没有规定引号、括号和书名号等成对标号的宽度必须是一个全角空格宽度,但在许多中文字体中(如方正兰亭黑),引号的宽度其实是一个全角空格的宽度,在
> Windows 下更加明显。而浏览器显示引号和英文引号一样常常是因为它们占用的是同一个 Unicode 编码,于是依据
> font-family 的设置,常常就从英文字体中取用引号的 glyph 了。
>
> “在英文与引号之间是否要插入空格呢?”
> 当然不用。因为在英文文本中,英文与引号之间本来就是没有空格的;而中文文本中,中文与引号之间也是没有空格的;于是综合二者的习惯,不用空格。
>
> 在 2010年10月2日 上午9:13,John Hax <johnhax@gmail.com> 写道:
> >
> 在中文为主的混排文本里,首先我们遵循的是中文用户的习惯。对于大多数情况,中文里混合的只是一两个单词,尤其是缩写词,因此手动插入空格是额外的负担(例子:中文HTML同乐会)。所以我认为手动插入空格只是排版软件本身的不足而引发的一个不怎么好的解决方案。
> > 再举一个例子,当你在中文里引用一段英文时,如“HTML5 Working
> Group”,在英文与引号之间是否要插入空格呢?这里的问题是,引号是通用的。
> >
> > 2010/10/1 梁海 <lianghai@gmail.com>
> >>
> >> > > 使用 <span lang="XX">
> >> > > 把外文跟中文隔開也是有語意的,而且比直接用空白更好。在 OpenOffice.org
> >> > >
> 上不輸入空白,軟體會自動幫你以小於一半型空白的寬度將西文和中文隔開,我想大家更認同@個作法。在網頁上預設沒法@樣呈現,所以大家都習慣了使用半型空白。而中文遇到日文、韓文等方塊文字的時候,應該不會用空白隔開吧,此時如何表達語意?證明鍵入空白以表達語意的說法是待商議的。
> >>
> >> 大概我没有表达清楚我的意思。
> >>
> >>
> >>
> 我认为在外文和中文之间插入的这个空格有良好的语义,并且这个语义不是平白无故创造的——这个语义来自于外文的断词习惯。正因为这个位置处于外文和中文之间,所以它得尽量遵循两种文字双方的排版习惯,作为过渡和衔接。
> >>
> >>
> 中文不要求空格断词,而外文要求,所以这个过渡区域使用两边的需求之和,即使用空格。同理,如果在印地语(Hindi)的天城文文本流中夹杂了英文,则天城文印地语要求空格,英文也要求空格,于是在两种语言的交界处就用空格。
> >>
> >>
> 而“中文遇到日文、韓文等方塊文字的時候”,因为日文不要求空格,中文也不要求空格,所以我们不加空格。我对韩文了解很少,没怎么见过中韩混合的文本,只知道韩文本身文本中也有很多空格。
> >>
> >>
> >>
> 所以我说的“鍵入空白以表達語意”的事,指的是一种兼顾两种文字排版习惯的处理方法,这种常见的处理方法所表达的语义尽量兼容了两种文字。这个语义不是故意通过插入空白产生的,而是这么多年来无数的作者通过直觉确定的。
> >> 我只是在分析这个如此流行的处理手段的合理性。
> >>
> >> > 個人也是覺得不應該直接用空白隔開漢字與西文,目前office軟體的做法還是比較好的。
> >> > 英文word與word間依賴空白格開,但漢字係則是靠「經驗」與標點符號。直接用空白鍵分隔的話,
> >> > 馬上會遇到的問題就是斷行。文字layout系統沒有處理好的話,會從中英文空白的地方斷開折行。
> >>
> >> 各类 office 软件以及专业排版软件如 InDesign 都有成熟的把中文和外文分隔开的能力(比如 InDesign 的默认设置是
> >> 1/4 全角(全形)空格宽度),这是因为不少作者不懂得应当在中文与外文之间插入空格,而排版软件自身又不应该去改变文本内容(如插入空格)。
> >> 关于“斷行”,这是另一个严重的问题了,浏览器中连英文的 hyphenation
> >> 都支持得不好,更不必说中外文混合时的断行问题了。不过,在如今的很简陋的断行算法下(如 Gmail
> >> 的断行算法),我宁愿让浏览器从中外文分隔的空格处断行。
> >>
> >> > 所以office類軟體才需要使用特別的間隔格開,而不是直接使用空白。
> >>
> >> 这样回溯 office 类软件使用“软间隔”而不是硬性插入空格的原因,似乎不太合适。毕竟各类 office
> >> 类软件的断行算法是否成功并不是依赖于中外文之间是否已插入空格的,这些软件对中文这样的不使用空格的文字的默认做法本来就都是自由断行。
> >>
> >> 梁海
> >>
> >>
> >> 在 2010年9月30日 下午9:49,Yuan Chao <yuanchao@gmail.com>写道:
> >> >
> >> > 2010/9/30 Ethan Chen <chief@ethantw.net>:
> >> >
> >> > > 其实在汉字与"通过空格来断词的外文文本"之间插入的空格并不是纯粹的"presentation",它是有语义的。
> >> >
> >> > > 它的语义同它在外文文本中的语义类似,都是把词语断开。
> >> >
> >> > (恕刪)
> >> >
> >> > > 使用 <span lang="XX">
> >> > > 把外文跟中文隔開也是有語意的,而且比直接用空白更好。在 OpenOffice.org
> >> > >
> 上不輸入空白,軟體會自動幫你以小於一半型空白的寬度將西文和中文隔開,我想大家更認同@個作法。在網頁上預設沒法@樣呈現,所以大家都習慣了使用半型空白。而中文遇到日文、韓文等方塊文字的時候,應該不會用空白隔開吧,此時如何表達語意?證明鍵入空白以表達語意的說法是待商議的。
> >> > 個人也是覺得不應該直接用空白隔開漢字與西文,目前office軟體的做法還是比較好的。
> >> > 英文word與word間依賴空白格開,但漢字係則是靠「經驗」與標點符號。直接用空白鍵分隔的話,
> >> > 馬上會遇到的問題就是斷行。文字layout系統沒有處理好的話,會從中英文空白的地方斷開折行。
> >> > 所以office類軟體才需要使用特別的間隔格開,而不是直接使用空白。
> >> >
> >> > > 還有 CSS 的 lang 無法分辨漢字跟非漢字,如果是 <span lang="ja">ようこそ</span> 還是會有空白。
> >> > > 再提回去一下,<span lang="ja" class="asian"> 加入一個 asian 分類表示亞洲方塊文字,或是直接在
> CSS
> >> > > 裡用
> >> > > :not(:lang(ja)) 避開 ja、kr 等方塊字,@樣就不會有空白了。
> >> > @裡,CJKV的處理應該是一樣的吧?
> >> >
> >> >
> >> > > 在 Sep 12, 2010 11:36 PM 時, 梁海 寫到:
> >> > >
> >> > > 其实在汉字与"通过空格来断词的外文文本"之间插入的空格并不是纯粹的"presentation",它是有语义的。
> >> > >
> >> > > 它的语义同它在外文文本中的语义类似,都是把词语断开。
> >> > >
> >> > >
> 我们说的"美觀"和"字詞辨識度",如果深究的话,还真不是纯粹从视觉上考虑的呢----这里面有语义的考量;我们用半角空格(半形空白)把外文和中文隔开,利用视觉的间隔来体现语义的间隔。很大程度上,也正因为这种插入空格的做法是有利于语义的,它受到大家的认同。
> >> > >
> >> > > 不好意思,顺便说一下,似乎由于大陆和台湾的译法不同,所以大陆的译名"语义"和台湾的"語意"并不是单纯的简繁对应,这个很有趣。
> >> > >
> >> > > 梁海
> >> > >
> >> > > 在 2010年9月12日 下午8:09,Ethan Chen <chief@ethantw.net> 写道:
> >> > >
> >> > > 講英文其實不太準確:「拉丁字母跟亞洲的方塊字之間需要有個間隔。」才對
> >> > >
> >> > > 如果不嫌麻煩,現在可以@樣寫:
> >> > >
> >> > > 用法文說你好<span lang="fr">bonjour</span>!
> >> > >
> >> > >
> >> > > CSS:
> >> > >
> >> > > article p span:not(:lang(zh)):before,
> >> > >
> >> > > article p span:not(:lang(zh)):after {
> >> > >
> >> > >       content: " ";
> >> > >
> >> > >       font-size: .05em;
> >> > >
> >> > > }
> >> > >
> >> > > 讓字體大小為 0.05em 可以隔出有效間隔,但是遇到標點符號就不會太突兀。如果 HTML 裡原本就有放空白隔開,也不會變成兩個空白。
> >> > >
> >> > > 還有 CSS 的 lang 無法分辨漢字跟非漢字,如果是 <span lang="ja">ようこそ</span> 還是會有空白。
> >> > >
> >> > > 當然@個方法是太麻煩了。除非拿 JS 寫。
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > 在 Sep 12, 2010 10:04 PM 時, Mark Chao 寫到:
> >> > >
> >> > > 之前在避頭點的討論中有提到,想說能不能把@單獨拿出來討論,也不知道@是否可以在 html @裡提(還是有 CSS 的討論區可以提)
> >> > >
> >> > > 在中文世界裡,一篇文章混有一些英文字是很正常的。當我打文章碰到@些情況時,總是有個小小地困擾。就是中英文字要不要間隔出來。
> >> > >
> >> > > 通常如果在中文與英文之間手動插入半形空白會比較美觀,也能提昇字詞辨識度。但是@也是有例外的,比如說「我有一些
> >> > >
> >> > > DVD。」,通常全形標點符號跟英文就不會特地間隔開來。
> >> > >
> >> > > 但是充其量,插入半形空白並不是完美的方法,首先@已經把 presentation 帶入應該只有語意的 html
> >> > >
> >> > > 中。而且半形空白的大小很死,不能作到一般文書軟體的等級(像是 OpenOffice
> >> > >
> >> > > 就會自動幫你把英數與中文字元以空白隔開,而且距離的拿捏也比我手工使用一個半形空白來的好。)
> >> > >
> >> > > 有沒有辦法指引遊覽器開發相關的功能,以便有目前文書軟體就有的中英文字自動隔開的功能呢?
> >> > >
> >> > > Ubuntu 對於中英混雜文件的建議
> >> > >
> >> > >
> >> > >
> http://wiki.ubuntu.org.cn/TranslatorsGuideline#.E5.85.B3.E4.BA.8E.E7.A9.BA.E6.A0.BC
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Yuan Chao
> >
> >
>

Received on Tuesday, 5 October 2010 16:03:49 UTC