Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

文本中多处中西混排没有依照 3.2.2,3.2.4 留出空白。 #14

Closed
Dr-How opened this Issue Apr 1, 2015 · 22 comments

Comments

Projects
None yet
9 participants
@Dr-How
Copy link

Dr-How commented Apr 1, 2015

不知这是否构成问题。举两个例子:

  • 3.2.1 缩写处,1999_年,ASCII_字元,等;
  • Abstract 中多处 W3C 之后没有留空;

似乎还有很多。

@Dr-How Dr-How changed the title 文本中多处中西混排没有依照 3.2.2 留出空白。 文本中多处中西混排没有依照 3.2.2,3.2.4 留出空白。 Apr 1, 2015

@r12a

This comment has been minimized.

Copy link
Contributor

r12a commented Apr 1, 2015

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.)

@bobbytung

This comment has been minimized.

Copy link
Contributor

bobbytung commented Apr 1, 2015

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

@siusin

This comment has been minimized.

Copy link
Contributor

siusin commented Apr 1, 2015

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

@lianghai

This comment has been minimized.

Copy link
Contributor

lianghai commented Apr 2, 2015

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

@bobbytung

This comment has been minimized.

Copy link
Contributor

bobbytung commented Apr 2, 2015

原則上:

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

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

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

@lianghai

This comment has been minimized.

Copy link
Contributor

lianghai commented Apr 2, 2015

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

@ethantw ethantw closed this in e2a3996 Apr 2, 2015

@jjgod

This comment has been minimized.

Copy link
Contributor

jjgod commented Apr 6, 2015

原則上:

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

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

@ethantw

This comment has been minimized.

Copy link
Member

ethantw commented Apr 6, 2015

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.

@ethantw

This comment has been minimized.

Copy link
Member

ethantw commented Apr 6, 2015

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.

@upsuper

This comment has been minimized.

Copy link
Member

upsuper commented Apr 6, 2015

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.

@Dr-How

This comment has been minimized.

Copy link
Author

Dr-How commented Apr 6, 2015

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 notifications@github.com: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.

@upsuper

This comment has been minimized.

Copy link
Member

upsuper commented Apr 6, 2015

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.

@Dr-How

This comment has been minimized.

Copy link
Author

Dr-How commented Apr 6, 2015

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?

@ethantw

This comment has been minimized.

Copy link
Member

ethantw commented Apr 6, 2015

@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.

@bobbytung

This comment has been minimized.

Copy link
Contributor

bobbytung commented Apr 6, 2015

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.

@Dr-How

This comment has been minimized.

Copy link
Author

Dr-How commented Apr 6, 2015

@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.

@Dr-How

This comment has been minimized.

Copy link
Author

Dr-How commented Apr 6, 2015

@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.

@ethantw

This comment has been minimized.

Copy link
Member

ethantw commented Apr 6, 2015

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.

@ethantw

This comment has been minimized.

Copy link
Member

ethantw commented Apr 6, 2015

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.

@Dr-How

This comment has been minimized.

Copy link
Author

Dr-How commented Apr 6, 2015

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.

@hax

This comment has been minimized.

Copy link

hax commented Apr 7, 2015

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

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

@Dr-How

This comment has been minimized.

Copy link
Author

Dr-How commented Apr 7, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.