A return code between CJK character and html tag or spaces convert an extra space

RESOLVED DUPLICATE of bug 1081858

Status

()

Core
Layout: Misc Code
RESOLVED DUPLICATE of bug 1081858
15 years ago
6 months ago

People

(Reporter: Yuying Long, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {intl})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Updated

15 years ago
Keywords: intl
QA Contact: ruixu → ylong

Comment 1

15 years ago
giving to shanjian
Assignee: yokoyama → shanjian

Comment 2

15 years ago
cc to smontagu.

Comment 3

15 years ago
accepting
Status: NEW → ASSIGNED

Comment 4

14 years ago
Created attachment 113290 [details]
testcase

Comment 5

14 years ago
Created attachment 113291 [details] [diff] [review]
patch

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.

Comment 6

14 years ago
Created attachment 113292 [details]
screen shot

Comment 7

14 years ago
Created attachment 113902 [details] [diff] [review]
patch

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
Attachment #113291 - Attachment is obsolete: true

Comment 8

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

Comment 9

14 years ago
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.

Comment 10

14 years ago
Created attachment 114546 [details] [diff] [review]
patch for mozilla-1.3b
Attachment #113902 - Attachment is obsolete: true

Updated

14 years ago
Attachment #114546 - Flags: review?(shanjian)

Comment 11

14 years ago
Created attachment 117344 [details]
testcase3

Comment 12

14 years ago
Created attachment 117345 [details]
screen shot of testcase3

Comment 13

14 years ago
Created attachment 117346 [details] [diff] [review]
patch
Attachment #114546 - Attachment is obsolete: true

Comment 14

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

Comment 15

14 years ago
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)..
Assignee: sli0262 → misc
Status: ASSIGNED → NEW
Component: Internationalization → Layout: Misc Code

Updated

14 years ago
Attachment #114546 - Flags: review?(sli0262)
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
Assignee: layout.misc-code → masayuki
Depends on: 289130

Updated

12 years ago
Blocks: 104960
Depends on: 295483
Blocks: 289130
No longer depends on: 289130
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?

Comment 18

12 years ago
(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. 
QA Contact: amyy → layout.misc-code
Assignee: masayuki → nobody
This sounds like something should be fixed by bug 1081858, although the second testcase has not been fixed yet because of the extra whitespaces.
Status: NEW → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1081858
You need to log in before you can comment on or make changes to this bug.