Build: 07-08 1.0.1 branch build This is for left over problems in bug 135323. After fix for bug 135323, there are still two problems: 1. When there is a return code HTML tag mixed together with character(s), there still like "an extra space" shows in browser window. http://www.asahi-net.or.jp/~wq6k-yn/para.html Please see the screen shot for detail: http://bugzilla.mozilla.org/attachment.cgi?id=89971&action=view Notice when copy/paste the string from Broswer window to Composer, seems won't see the extra space. 2. When the HTML source has space(s) between return code, like page: http://www.php.net/manual/ja/function.setcookie.php or: http://www.vinelinux.org/ There is a single byte space between 2 characters. On Netscape I can highlight the space between characters while on IE I can not.

giving to shanjian

cc to smontagu.

accepting

A return code with the CJK character is skipped. It does not skip, when if follows a space code. It does not correspond to a string search yet. The effect of a patch was checked by mozilla-1.2.1.

The patch for searching a string mixed CJK characters with a '\n' was added. Related bug report is shown below. Bug-org 166127 Search string in Japanese doesn't match exactly

> Bug-org 166127 Bug 166127 Search string in Japanese doesn't match exactly

ylong-san said: 1. When there is a return code HTML tag mixed together with character(s), there still like "an extra space" shows in browser window. 2. When the HTML source has space(s) between return code, there is a single byte space between 2 characters. This patch is related only to the first problem. We may not desire to skip a space that is inserted explicitly between an English character and a CJK character although we may desire to skip space(s) for the indent after a new-line. I wish to examine the second problem after the first problem fixes.

The space following a new-line is also deleted. It is a patch for release version 1.3b. I will rewrite for 1.3.

It's not just layout (patches here also deal with 'find'), but layout takes a significant portion of patches here. so, I'm changing the component (not sure exactly which component of layout)..

Taking this. I think that this should be fixed as: { linefeed-treatment: auto; white-space-treatment: ignore-if-surrounding-linefeed; } See http://www.w3.org/TR/css3-text/#white-space-props

Jungshik: Currently, we always remove the line-feed if its each sides are Kanji or Kana. I.e., ab<- cd In this case, if 'b' and 'c' are IS_CJ_CHAR, we remove the line-feed character. I think this behavior is wrong for Korean. Do you think it?

(In reply to comment #17) > Jungshik: > > Currently, we always remove the line-feed if its each sides are Kanji or Kana. > I.e., > > ab<- > cd > > In this case, if 'b' and 'c' are IS_CJ_CHAR, we remove the line-feed character. > > I think this behavior is wrong for Korean. Do you think it? It depends. If lines are broken (by the author of a document by inserting 'linefeed' character) within a single word, the current behavior is correct. If lines are broken between two adjacent words, the current behavior is wrong. It's far from trivial to distinguish between two cases automatically. However, it's rather rare that a linefeed is inserted by the author of a document to break lines *within* a word so that you have a point. We'd better NOT remove 'linefeed' between two Korean syllables.

This sounds like something should be fixed by bug 1081858, although the second testcase has not been fixed yet because of the extra whitespaces.