文本中多处中西混排没有依照 3.2.2，3.2.4 留出空白。 about clreq HOT 23 CLOSED

原則上：

文稿間中文與英文不加空白。
也不使用JavaScript Polyfill。

Any particular reasons for that? Since text-spacing is not technically ready I do prefer spaces.

from clreq.

原則上：

• 文稿間中文與英文不加空白。
• 也不使用JavaScript Polyfill。

我之前寫「簡單做好中文排版」時，也遇到讀者來信這麼問。回覆就是：
目前text-spacing還在CSS Text Level 4草稿裡，就是以目前標準技術做不到。

可能要請梁海與各位多擔待，撰寫時就統一體例，不加中西文間空白。

from clreq.

The jlreq folks had some discussions on this issue for Japanese too. Currently jlreq has the same approach as ours (in terms of treating the spacing between Han and Latin characters as a kind of styling, instead of adding U+0020). I agree with this direction too (although sometimes I do add spaces when there is no better solutions available).

(Another advantage is that the spacing between Chinese and Latin text can be customized, instead of relying on the width of U+0020, which is uneven font by font.)

from clreq.

There used to be a CSS property, auto-space, specifically for separating Chinese characters from latin/numbers. It was implemented by IE. I have to admit that i'm not fully conversant with its current status, but i seem to remember that it was removed from the CSS spec until a later date. I think it wasn' implemented by Firefox/Chrome. May be worth investigating.

In general, i think we should probably review the styling for the layout requirements doc before we publish the FPWD to see what things we can influence by adding a local style sheet – so that the document follows, as much as possible, what we preach in the document itself. (To be honest, i don't think that was done for the jlreq doc.)

from clreq.

It might be text-spacing in CSS Text Module Level 4.

from clreq.

@lianghai
Any thoughts? Shall we remove this rule from the document or mark it as a suggestion?

from clreq.

这份文档不应使用 text-spacing 那样还未受到广泛支持的 CSS 属性或者特殊的 JavaScript 处理，否则文档内不稳定的排版样式会令读者困惑。
在目前 CSS 还没能实现这些高级排版特性的情况下，我建议我们应当使这份文档尽量在「纯文本」层面上正确。我个人偏好在纯文本情况下使用中西文间空格字符，但当然，因为中西文间空格字符是有争议的，该文档全文不用中西文间空格字符也是个足够明确的做法。

from clreq.

好，那大家就统一不加空格吧（将中西文间距视作「样式」而非「内容」）。
这样明确的态度很好。

from clreq.

Bobby and I think the spaces are presentational not semantic. Inserting spaces in between is somehow like indenting text/paragraphs with spaces. It is also a convention used by Wikipedia and JLReq.

from clreq.

If we choose to believe that the spaces between Hanzi and Western scripts are semantic, which I have no problem with. But maybe section 3.2 should not even be included in the document. The main purpose of CLReq is about text layout, not telling people to spell correctly, use proper characters or type spaces after Western periods.

from clreq.

Things like “typing spaces after Western periods” probably should at least be mentioned in a note, since it could have impact on layout. I think probably everything about space is worth being mentioned in a layout requirement doc.

from clreq.

Spaces between Chinese characters and western words can be semantic, but also part of the style.

Check these examples:

• In Chinese, the character 打 means love.
• 微软使用 das Auto 作为广告语。
  In these examples, the spaces are semantically necessary.

For only one word in Chinese context, the spaces are also important for the style.
If the technique is not ready for this, we simply input the spaces manually in the raw text.

It seems that, you regard everything input by human as "content", and everything decided by code as "style".  This is ridiculous.  Style was already there since the beginning of printing, and is always manually taken care of.  We input line breaks, input indentations, all manually.  What's the problem of inputting the spaces manually.

Spaces are part of the style that are semantically important.
When the technique is not yet ready, we input spaces manually.

Am 06.04.2015 13:01 schrieb Chen Yijun [email protected]:If we choose to believe that the spaces between Hanzi and Western scripts are semantic, which I have no problem with. But maybe section 3.2 should not even be included in the document. The main purpose of CLReq is about text layout, not telling people to spell correctly, use proper characters or typing spaces after Western periods.

from clreq.

When a space is semantically necessary, we certainly should add a whitespace in content. However, when we inputing whitespaces only because technique is not ready for styling, I'd tend to avoid doing so, especially given that whitespaces could have semantic meaning.

from clreq.

You can not simply say that spacing is content or style.
You can not simply separate style from content.
Spacing is content AND style.

Do you tend to avoid indentations when your editor does not do it automatically?
Do you tend not to center / emphasize / indent the title when your editor is too primitive?
Do you tend not to do anything about style when you use a typewriter?

from clreq.

@Hao-Chen:

It is my personal opinion that the spaces between Hanzi and Western scripts are not semantic. And I agree that these arguments won't come to an end in the near future. All I was saying is, if we believe the spaces in between are semantic, then it wouldn't be logic to have such rules in this document.

The first example you provided is in English. English context, English rules: words are separated by spaces. In Chinese context, like the second example of yours, we conventionally use no semantic spaces to separate words, hence the use of spaces between Hanzi and Western scripts do not seem convincing.

If the technique is not ready for this, we simply input the space manually in the raw text.

By saying so, you're actually implying the idea that the spaces between Hanzi and Western scripts are presentational. ‘The technique’ you were referring to is actually styles and the input spaces is like a hack trying to implement such effect.

from clreq.

It's FPWD, so we do nothing to styling as we do not separate this document into simplified and traditional Chinese as well. In the process, we just decide editors should manually add space between Hanzi and Latin words or not, I suggest not.

If editors agree, we can go on.

But discussion here is quite important. it still a problem we will face with implementation.

from clreq.

@bobbytung @ethantw:

I disagree with the idea of completely separating content / semantic from style / layouts.
You can not exclude the rule simply because you think "it's not about style".
You can not ignore the rule simply because you think "it's not semantic".
People like me disagree with either of the two statements.
For me, spacing is about style and is semantic.

In my second example, let us try:
微软使用das Auto作为广告语
The space there divides the sentence into two segments.
You can argue that it's semantically correct, but, I hope you agree, it's ugly.

I CAN however live with this disagreement.
Then I disagree with the idea that anything purely about style should not be present in the raw text.
Being "presentational" is not a characterization of style. The styling effects are realized ("hacked" in your word) manually since the era of typewriters, I don't see any reason of completely relying on techniques.

You can suggest or discourage manually adding spaces.
But being "style" not is not a valid reason for either decision.

from clreq.

@ethantw

The main purpose of CLReq is about text layout, not telling people to spell correctly, use proper characters or type spaces after Western periods.

In this case, is Section 3.1.1 (usage of punctuations) logic to be included in this guide? I find this part purely about usages, nothing about style.

from clreq.

Sec. 3.1.1 is not only of the usage but is actually the introduction to the entire sec. 3.1, which classifies the punctuation marks, indicates their Unicode char codes, their presentational styles, their differences between TC-SC and whether or not one mark is adapted in publications nowadays. The usage helps determine their definitions and avoid misleading cases. For example, 破折號 can sometimes look exactly like 連接號. I would say that sec. 3.1.1 is about text layout.

from clreq.

In my second example, let us try:
微软使用das Auto作为广告语
The space there divides the sentence into two segments.
You can argue that it's semantically correct, but, I hope you agree, it's ugly.

I do agree it is ugly. But I still believe it's layout engine's problem, not mine, not typers'. I also think the following case is ugly:

何謂「標點『擠壓』」？

But I would not use the half-width punctuation simply to present the effect of compression of punctuation.

from clreq.

Glad that we both agree that these examples are ugly.
In your example, few can be done to save the situation. Change to half-width punctuations would break the consistency of the whole text. This would destroy the style instead of improving it. I would suggest the typer / author to rephrase and avoid this.
In my example, instead, the typer only needs to add two spaces. This does no harm to the content, improves the style and makes the text easier to read. It makes sense to suggest this practice.

You insist to leave spacing to the engine, simply because you want to stick with the separation principle. But in real life, it is not always clear what is content and what is presentation. We should try to separate as hard as we can, but we should never misinterpret an element to make our life easier. We should accept the fact that some elements are confusing and may never be completely separated.

Style effects is something that editors should try their best to realize. If the layout system can handle it, thank god. Lack of such a system is not an excuse for editors to just leave it. The editor should make reasonable attempt to improve the style. The note of Sec. 3.2.2 provide an alternative practice when the automatic spacing is not available. The guide itself should follow this note.

from clreq.

@Hao-Chen When you said "ugly", it's obvious you are talking about "style".

另外，在目前这个阶段，这草案本身的排版问题（还有诸如繁简问题）是小问题，不必纠结。

from clreq.

Yes, I was talking about a style, which I personally find also semantically necessary but won't insist, which should be manually taken care of since the technique is not ready. I accept the opinion of "not semantic", never admit it.

After their explanation on the decision, this is now an issue about keeping of removing this requirement from the text.

from clreq.