A return code between the two CJK characters is converted to a space code

VERIFIED FIXED

Status

()

VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: hsaito54, Assigned: shanjian)

Tracking

({intl})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 rtm])

Attachments

(4 attachments, 10 obsolete attachments)

(Reporter)

Description

17 years ago
A space code between the two kanji characters is desirable to remove.

For example, this Japanese sentence
"¤¢
¤¤"
is displayed "¤¢ ¤¤" but I expect to display "¤¢¤¤" without a space.
-> Int
Assignee: Matti → yokoyama
Component: Browser-General → Internationalization
QA Contact: imajes-qa → ruixu
(Reporter)

Comment 2

17 years ago
Created attachment 77569 [details] [diff] [review]
a patch to remove a space between two kanji caracters

Please apply this patch next to apply a patch 
"patch to wrap long word by key-characters" at
"http://bugzilla.mozilla.org/attachment.cgi?id=75233&action=view" in
 "http://bugzilla.mozilla.org/show_bug.cgi?id=95067".
(Reporter)

Comment 3

17 years ago
Created attachment 77572 [details]
testcase

Comment 4

17 years ago
This bug is related to bug 95067.

I believe most Japanese people prefer that a line-break isn't rendered as space.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: Other → All
(Reporter)

Comment 5

17 years ago
Created attachment 77597 [details] [diff] [review]
additional patch #1

I made a error in my patch carelessly.
I correct errors with this patch program.

Updated

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

Comment 6

17 years ago
saito-san:  Your patch looks simple; but I think the patch is rotten.
               Can you update the patch for the current trunk?  I'd like to
apply the patch
               to verify the fix.  Thanks
(Reporter)

Comment 7

17 years ago
Created attachment 80550 [details] [diff] [review]
new patch to remove a space between two kanji caracters 

The patch was remade.

Comment 8

17 years ago
assign to shanjian.
Shanjian: can you review his code?  It's in the layout. Thanks
Assignee: yokoyama → shanjian
(Assignee)

Comment 9

17 years ago
saito san,
I think '\n' should be removed only between CJK characters. That's say inside
function "ScanNormalWhiteSpace_F", you need to check character before and after
'\n' before setting the flag. If '\n' is the last character in this fragment, it
is OK to only check its precedence. (This will happen when text span multiple
fragment.) 

I am also wondering about this change:
-  *aContentLenResult = offset - mOffset;
+  *aContentLenResult = offset - save_offset;

Why did you use save_offset instead of mOffset, which is more updated? I assumed
you have tested the former one and it didn't work well. But I would like to know
why. 







Status: NEW → ASSIGNED
(Reporter)

Comment 10

17 years ago
To be sure, my patch program is wrong.
Testing the following pages, it found two errors.

http://www.asahi-net.or.jp/~wq6k-yn/para.html

Every time Reload, a vertical scrill bar moves the first error.
But returning a program to a basis,

    *aContentLenResult = offset - mOffset;

the error was corrected.

A patch needs to be added to correct the next error.
The next sentence is not sometimes displayed accurately.

用途を詳しく分析した上で DTDを設計すれば、そのようなこと
はあまり起きない (かもしれない)。しかし、                 <===== error
HTMLのように一つの                                       <===== error
DTDを様々なタイプの文書に用いるのでは、この種の不都合は避  <===== error
け難い。

A variable contentLength is in the function nsTextFrame::MeasureText() at 
nsTextFrame.cpp.

When a space between Kanji characters is deleted, 1 must be subtracted from 
this variable.
(Reporter)

Comment 11

17 years ago
Can't I write the document of Japanese?

用途を詳しく分析した上で DTDを設計すれば、そのようなこと
はあまり起きない (かもしれない)。しかし、
HTMLのように一つの
DTDを様々なタイプの文書に用いるのでは、この種の不都合は避
け難い。
(Assignee)

Comment 12

17 years ago
>>Can't I write the document of Japanese?
What do you mean? As a test case, that's fine. But if you plan to use japanese
for communication, I am incapable to read it.  
(Reporter)

Comment 13

17 years ago
I made a mistake.
I wrote in an Shift-JIS code and displayed it in an EUC-JP code.

> I think '\n' should be removed only between CJK characters.

I appreciate your suggestion.
I will try to investigate whether a patch can act only to the CJK characters.
(Reporter)

Comment 14

17 years ago
Created attachment 82001 [details] [diff] [review]
patch to remove a space between two CJK caracters 

The patch was remade.
It is happy if you can evaluate.
(Assignee)

Comment 15

17 years ago
saito san,
I really appreciated your help one this issue. This part of code is complicated
and very sensitive, so please be patient with me. Please also excuse me if my
question does not make sense to you. I am learning this part of code as well. 
Several suggestions:
1, It is probably not a good idea to add Probe method to word breaker. You can
add the macro to local file directly. In different places, we may have different
definition of CJK char, so it is fine for me to define it multiply. Of cause, if
we can add widely used CJK macro to XPCOM module to avoid this, it will be nice.
But let's leave that for later.
2. Can we avoid the use of SpaceInfo? In nsTextTransformer::GetNextWord, we have
some code dealing with German Szlig character, we need to transform this one to
"SS". I assume you can do it the same way. But I am not very sure. I hope
DeleteOneChar can also be avoided.


(Reporter)

Comment 16

17 years ago
I am sorry, there was a spelling mistake.
> Every time Reload, a vertical scrill bar moves the first error.
Every time Reload, a vertical scroll bar moves the first error.
> patch to remove a space between two CJK caracters 
patch to remove a space between two CJK characters 

> DeleteOneChar can also be avoided.

If I can also do, I do not want to use this function.
But a space will remain by the copy & paste using the mouse.
The place of correction was not able to be found.

Summary: A return code between the two kanji caracters is converted to a space code → A return code between the two CJK characters is converted to a space code
(Reporter)

Comment 17

17 years ago
please let me know.

Although the character is stored to the buffer "mTransformBuf.mBuffer",
I recognize that this buffer is not used by the copy & paste using the mouse.
Is it right?

If right, when copying & pasting by the mouse,
where is the processing which transposes a return code to a space or 
the continuous space to one space?
(Assignee)

Comment 18

17 years ago
I can't answer your question without looking into the code. But I guess that we
do not do any transformation for copy-n-paste. If we do collapse multiple spaces
to one in copy-n-paste, we need to do this transformation (remove space between
kanji) in the same way. 
(Reporter)

Comment 19

17 years ago
Created attachment 82597 [details] [diff] [review]
patch v4 to remove a space between two CJK characters

The patch was remade again.
Please give me a review.
(Assignee)

Comment 20

17 years ago
This patch is acceptable to me, but the changes in nsTextFrame.cpp does not seem
necessary. So could you take one more look?

(Reporter)

Comment 21

17 years ago
The changes in nsTextFrame.cpp is required in order that a variable "totLen"
in nsPlainTextSerializer.cpp may acquire the right length of a character
sequence.

Is it better to look for other methods for a its variable acquiring the length
of a character sequence?

content/base/src/nsPlainTextSerializer.cpp:
  1513  void
  1514  nsPlainTextSerializer::Write(const nsAString& aString)
  1515  {

  1524    PRInt32 totLen = aString.Length();

An example is shown below, "xx" shows the Kanji character of one character.

"xx
yy"

The value of a variable "totLen" is 2, when a patch is not applied to
nsTextFrame.cpp.
However, the value should be 3.
(Assignee)

Comment 22

17 years ago
Saito san, 
Sorry for not being able to response promptly. I was busy in fixing some urgent
issues. I did spend some time today and check your patch carefully. I still
could not understand why the change in nsTextFrame.cpp is necessary. Display and
copy-n-paste works fine without that change. So could you post a test case to
show the problem when that part is not there? thanks.
(Reporter)

Comment 23

17 years ago
I appreciate for your preview and suggestions.

Please test a testcase "Created an attachment (id=77572)".
Can you copy "¤¢¤¤" using the mouse and paste it?

When a patch was not applied to nsTextFrame.cpp , "¤¢ " was pasted.
I tested by the version 0.9.8.
The latest version cannot immediately be made up, but should I do so?

P.S.
"¤¢¤¤" is "xx" and "yy" that indicates two Kanji characters.
"¤¢ " is "xx" and a white space.
(Reporter)

Comment 24

17 years ago
I am sorry, it mistook again.
> I appreciate for your preview and suggestions.
I appreciate for your review and suggestions.
(Reporter)

Comment 25

17 years ago
The previous message containing kanji characters was written in the code of
EUC-JP.
(Assignee)

Comment 26

17 years ago
Created attachment 82989 [details] [diff] [review]
patch v5,
(Assignee)

Comment 27

17 years ago
Saito, I finally got enough time to understand all your changes. I changed the
patch to make it more local. (I hope you don't mind my modification.) The idea
is the same. Please review my patch to see if I missed any of your points. I
appreciate you contribution, this is a complicate area and you did a good job. 
(Reporter)

Comment 28

17 years ago
I agree with your changes, but the next program needs to change.

nsTextTransformer.cpp: old
+          if (firstChar == '\n' && 
+              offset - mOffset == 1 && 
+              fragLen > offset) 

nsTextTransformer.cpp: new
+          if (firstChar == '\n' && 
+              offset - mOffset == 1 && mOffset > 0 &&
+              fragLen > offset) 

This change is added and a test is O.K.
(Assignee)

Comment 29

17 years ago
Created attachment 83046 [details] [diff] [review]
patch v6
(Assignee)

Updated

17 years ago
Attachment #77569 - Attachment is obsolete: true
Attachment #77597 - Attachment is obsolete: true
Attachment #80550 - Attachment is obsolete: true
Attachment #82001 - Attachment is obsolete: true
Attachment #82597 - Attachment is obsolete: true
Attachment #82989 - Attachment is obsolete: true
(Assignee)

Comment 30

17 years ago
good point. I updated the patch. Now let's ask for r/sr.

rbs/attinasi, could you give r/sr?

Comment 31

17 years ago
Comment on attachment 83046 [details] [diff] [review]
patch v6

-	 i = contentLen;
+	 if (1 == wordLen && contentLen == 2 && IS_CJK_CHAR(*bp)) {
+	   i = contentLen;
+	 } else {
+	   i = contentLen;
	 }

No need to duplicate the statement.

What happens when there are _multiple_ '\n' between the CJK chars?

I am not a big fan of macros defined in several places.
You can define IS_CJK_CHAR in one place (next to IS_HIGH/LOW_SURROGATE) in
intl/unicharutil/util/nsUnicharUtils.h
(Assignee)

Comment 32

17 years ago
Created attachment 83587 [details] [diff] [review]
patch v7

Moved macro to nsUnicharUtils.h.
Attachment #83046 - Attachment is obsolete: true
(Reporter)

Comment 33

17 years ago
> What happens when there are _multiple_ '\n' between the CJK chars?

One space is replaced, when two or more '\n' are between CJK characters, or 
when a space is included. It is the conventional processing.
(Reporter)

Comment 34

17 years ago
When changed into patch-v6 from patch-v5, a mistake occurs.
Please check.

patch-v5:
+          if (firstChar == '\n' && 
+              offset - mOffset == 1 && 
+              fragLen > offset) 
+          {

patch-v6:
+          if (firstChar == '\n' && 
+              offset - mOffset == 1 && 
+              mOffset > 0) 
+          {

new:
+          if (firstChar == '\n' && 
+              offset - mOffset == 1 && 
+              mOffset > 0 &&
+              fragLen > offset)
+          {
(Assignee)

Comment 35

17 years ago
Created attachment 85265 [details] [diff] [review]
patch v8
Attachment #83587 - Attachment is obsolete: true
(Assignee)

Comment 36

17 years ago
rbs/waterson, could you r/sr?

Comment 37

17 years ago
Comment on attachment 85265 [details] [diff] [review]
patch v8

I didn't understand the reply to my question about  what happens when there are
multiple '\n' and/or tabs and/or space chars in-between the CJK chars?
(Reporter)

Comment 38

17 years ago
Two or more '\n' between CJK characters replaces one space.
Although one or more TAB and spaces between CJK characters also replace one
space, the above both processing is the conventional processing and this patch
does not bar the processing.
(Assignee)

Comment 39

17 years ago
rbs, let me explain hideo's statement. We only remove a single return between 2
CJK characters. We do nothing to multiple return, tab, space, whatsoever. Why is
that? For tab, space, and other non-return space equivalent characters, we
believe user has a reason to put it there when it is there, so we don't want to
do anything. In case of multiple return, that's arguable. When user put a single
return between 2 CJK char, they just want to shorten line length and they expect
text flow to be continuous. We decide to only handle this situation and nothing
else. I personally believe hideo's approach is reasonable. To remove multiple
return between CJK char also make sense to me, but I didn't find it really
necessary.

Comment 40

17 years ago
Is there a real-life page with the problem? Something that has been bugging me
is why there wasn't a duplicate/precedent to this bug. (If there is one in
bugzilla, care to point it?).

What is conventional elsewhere (e.g., telegraphic text -- just a funny example)
might be irrelevant in HTML. Surely, there should be a real-life page, in this
massive web, with this bug? Is the patch not going to cause a suprise and
regress pages that have been using '\n' as end-of-word *and* end-of-line -- not
just end-of-text-line? Also, I wonder about the rendering of <pre>formatted
text, the patch might mess all that.

I applied the patch and it seemed to "fix" the testcase. I had some doubts about
the necessity of the plain-text part, but again, it might be the same doubt as
above (BTW, double-check/confirm that mInWhitespace is in sync).

Comment 41

17 years ago
Again, as a reminder, this isn't an easy area, and tip-toeing to arrive safely
is better -- although it might take longer. So bear with the picky r/sr.
(Reporter)

Comment 42

17 years ago
By the text of usual Japanese, a space is not placed between kanji characters.
In case a long document is edited, starting a new line, and continuing and
describing a text in the suitable place of immediately after a punctuation and
kanji characters other than a punctuation is performed ordinarily.

Please see the following examples (was written in the code of EUC-JP).
If HTML describes the text of 1, like 2, although it is visible like 3, we do
not desire a text of 3.

1,
ºé¤¤¤¿¡¢ºé¤¤¤¿¡¢ºù¤¬ºé¤¤¤¿¡£

2,
ºé¤¤¤¿¡¢
ºé¤¤¤¿¡¢
ºù¤¬
ºé¤¤¤¿¡£

3,
ºé¤¤¤¿¡¢ ºé¤¤¤¿¡¢ ºù¤¬ ºé¤¤¤¿¡£

It is possible to continue writing a Japanese text without a new-line for a long
time. However, it is pain for us.

It is checking that this patch does not influence the <pre> element.
(Reporter)

Comment 43

17 years ago
> Is there a real-life page with the problem?

It shows one example, but not a good example, since CSS is used and the space 
between kanji characters spreads, 

http://www.asahi-net.or.jp/~wq6 k-yn/para.html

> Something that has been bugging me is why there wasn't a duplicate/precedent 
to this bug.

The argument is made even now at Bugzilla-jp (http://www.mozilla.gr.jp/), and 
there is a contrary opinion about this affair.
That is, it says that it is the specification of HTML and the specification 
should be followed, and has been considered so until now.
(Reporter)

Comment 44

17 years ago
Sorry, it is the following URL.

http://www.asahi-net.or.jp/~wq6k-yn/para.html

Comment 45

17 years ago
> It is possible to continue writing a Japanese text without a new-line for a
> long time.

Do you mean that there are words that excessively long and cannot be broken by
users as they type them? Such a word would be weird to read...

> The argument is made even now at Bugzilla-jp (http://www.mozilla.gr.jp/), and 
> there is a contrary opinion about this affair.
> That is, it says that it is the specification of HTML and the specification 
> should be followed, and has been considered so until now.

I am leaning towards the opinion of leaving things as they are myself (i.e.,
retain the HTML-spec way). This will avoid undue uncertainties with <pre>, not
to mention the (still unknown) ramifications when typing in Composer.

Plus, IE6 does what Mozilla is currently doing, and a change will not only be
non-spec compliant, but it will also deviate from what other popular browsers
are doing.

Comment 46

17 years ago
> Do you mean that there are words that excessively long and cannot be broken by
> users as they type them? Such a word would be weird to read...

CJK text doesn't have a space between words. So, if somebody hates
current Mozilla behaviour, he/she have to write a paragraph in a single line.

IE6/Win doesn't display a line-break as a space.

Comment 47

17 years ago
> CJK text doesn't have a space between words. So, if somebody hates
> current Mozilla behaviour, he/she have to write a paragraph in a single line.

But if you use the Mozilla's editor, |nsJISx4501LineBreaker| does line-breaking
nicely as you type, right?
(Reporter)

Comment 48

17 years ago
It is different to everybody what is used for a text editor.

Can't it be interpreted as deletion being possible about the space between 
words by HTML 4.01 specifications depending on a each languege?

Comment 49

17 years ago
HTML spec:

<http://www.w3.org/TR/REC-html40/struct/text.html#h-9.1>
> This layout may involve putting space between words (called inter-word space),
> but conventions for inter-word space vary from script to script. For example,
> in Latin scripts, inter-word space is typically rendered as an ASCII space
> (&#x0020;), while in Thai it is a zero-width word separator (&#x200B;).
> In Japanese and Chinese, inter-word space is not typically rendered at all.

CSS spec:
http://www.w3.org/TR/2002/WD-css3-text-20020515/#linefeed-treatment
(Reporter)

Comment 50

17 years ago
> Plus, IE6 does what Mozilla is currently doing, and a change will not only be
> non-spec compliant, but it will also deviate from what other popular browsers
> are doing.

The specifications described by "9.1 White space" of HTML is right.
> In Japanese and Chinese and inter-word space is not typically rendered at all.
I believe that it is left to the browser how inter-word space is rendered.

I consider that those browsers force the custom of a Latin scripts on us.

Comment 51

17 years ago
Another real life example of this problem.

    http://alltheweb.com/

Comment 52

17 years ago
Oh, this one too.

    http://www.google.com/

To see the problem, have Japanese at the top of your preferred langage list,
and search something in Japanese.

Comment 53

17 years ago
http://www.asahi-net.or.jp/~wq6k-yn/para.html

Looking at that page, it looks bad. Although that page is intentionally creating
the problem, it can happen in real pages like machine generated output (e.g.
google). &#12288;
I think we want to fix this on the trunk.

Comment 54

17 years ago
I propose to fix this in branch so that it makes to Netscape 7 release.
We shouldn't ignore 2nd and 3rd mostly used language on the internet.

Comment 55

17 years ago
Taka, you can nominate this as nsbeta1 if you think this is important.
Please provide some info. 
1) How frequent does the user encounter the page with the problem.
2) How bad the problem can be? Please provide a screen shot.

Comment 56

17 years ago
Created attachment 88729 [details]
screen shot of the doc in comment 53

Naoki,

It's not a matter of how often users encounter this.  As far as we state that
Mozilla is HTML 4.0 compliant browser and it supports Chinese and Japanese,
the document in comment 53, which is error free HTML 4.0 Strict document, 
must be rendered as native language speakers expect.

Please see the screenshot and judge how bad we are doing with error free
HTML document.

This issue has been around since Netscape 4.0 and discussed on various ML, 
BBS, Newsgroup, etc.  I don't want to see people blaming on Mozilla/Netscape
about this issue anymore.

Nominating to nsbeta1.

Updated

17 years ago
Keywords: nsbeta1

Comment 57

17 years ago
Created attachment 88737 [details] [diff] [review]
patch v9

Exclude Korean from patch v8.
Attachment #85265 - Attachment is obsolete: true
(Assignee)

Comment 58

17 years ago
Comment on attachment 88737 [details] [diff] [review]
patch v9

r=shanjian
Attachment #88737 - Flags: review+
(Assignee)

Comment 59

17 years ago
I just put r=shanjian since this patch is originally proposed by saito, and new
one is touched by taka. 

chris waterson, could you please sr?
rbs, feel free to express your objection if you still have some. 

Comment 60

17 years ago
can we reduce this patch by take out the non essential change in
nsJISx4501LineBreaker.cpp
and +#define IS_CJK_CHAR(u)  in nsUnicharUtils.h

[adt2] since this a strong recommendation/complains from Japanese mozilla
community. 
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]

Updated

17 years ago
Blocks: 141008

Comment 61

17 years ago
Created attachment 89113 [details] [diff] [review]
patch v10

don't touch nsJISx4501LineBreaker.cpp.
Attachment #88737 - Attachment is obsolete: true
(Assignee)

Comment 62

17 years ago
After we added the macro to nsUnicharUtils.h, it does not make sense to keep
another copy in nsJISx4501LineBreaker.cpp. Since those are identical macro,
there should be no risk. I would suggest to use v9 instead of v10. 



Comment 63

17 years ago
Actually, IS_CJK_CHAR(u) is not used in this patch anymore because we have to 
exclude Korean from special case handling.  I added IS_CJ_CHAR() in 
nsUnicharUtils.h and that's the macro we are using.
(Assignee)

Comment 64

17 years ago
Comment on attachment 89113 [details] [diff] [review]
patch v10

I am Ok with v10.
Attachment #89113 - Flags: review+

Comment 65

17 years ago
Comment on attachment 89113 [details] [diff] [review]
patch v10

sr=waterson
Attachment #89113 - Flags: superreview+

Comment 66

17 years ago
checked into trunk.

/cvsroot/mozilla/layout/html/base/src/nsTextFrame.cpp,v  <--  nsTextFrame.cpp
new revision: 1.374; previous revision: 1.373
/cvsroot/mozilla/layout/html/base/src/nsTextTransformer.cpp,v  <--  nsTextTransf
ormer.cpp
new revision: 1.69; previous revision: 1.68
/cvsroot/mozilla/content/base/src/nsPlainTextSerializer.cpp,v  <--  nsPlainTextS
erializer.cpp
new revision: 1.60; previous revision: 1.59
/cvsroot/mozilla/intl/unicharutil/util/nsUnicharUtils.h,v  <--  nsUnicharUtils.h

new revision: 1.15; previous revision: 1.14
(Assignee)

Comment 69

17 years ago
I talked to naoki and we double checked the code. The patch will only affect
chinese and japanese characters. For characters of other languages, the behavior
should be the same. For verification testing, we can also use any non-chinese
and non-japanese website to verify this. Since '\n' is used in many long peice
of text.
If there is something, it shouldn't be difficult to identify. 
For chinese/japanese verification, see previous comment for testcases. Be sure
to test copy-n-paste. 

Comment 70

17 years ago
On 07-02 trunk build:

1. It works fine when a return code between 2 Japanese text characters. 
However, 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

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. 
I don't if it is OK, but on Netscape I can highlight the space between
characters while on IE I can not.

3. No Copy/Paste regression was found right now.

4. I don't find any regression with English or other languages so far. 

Comment 71

17 years ago
Created attachment 89971 [details]
a screen shot after fixed

Notice:
For the display in browser, there is no different with this case before or
after the fix.

When I copy/paste the string from Broswer window to Composer, the space will be
shorter.

Comment 72

17 years ago
Taka, the first two issues in Comment #70 were they intended to be fixed by the
last patch? If not, we can verify this as fixed.

Comment 73

17 years ago
>Taka, the first two issues in Comment #70 were they intended to be fixed by the
>last patch? If not, we can verify this as fixed.
Let me ask this to the original author of the patch.
Saito san, could you answer my last comment?  Is it okay for mozilla community
in Japan about the current level of the support (i.e. remaining problems are not
so important)?
(Reporter)

Comment 74

17 years ago
There are about three future examination matters.
A new-line replaces a space, without being deleted in the following examples.

(1) a new-line is between a Kanji character and an English character.
KK
HTML
KK

(2) the Kanji character is inserted into HTML tag 
KK
<a>KK</a>
KK

(3) there is a space following a new-line
KK
    KK

KK is the Kanji character of one character.
The user group of Bugzilla-jp examines whether deletion of a space is required.

Comment 75

17 years ago
Okay, please file a separate bug for those problems. This bug can be marked as
fixed. I think the current fix mostly covers exisiting problems. Nominate for
adt1.0.1
Keywords: adt1.0.1
Whiteboard: [adt2] → [adt2 rtm]

Comment 76

17 years ago
adding adt1.0.1- per ADT.  Let's get this in the next release.

Comment 77

17 years ago
> re: comment #59
>
> rbs, feel free to express your objection if you still have some.

I have been travelling, and was out of bugzilla. I don't like the fix very much
(especially that it doesn't cover everything and it is short-sighted for the
remaining parts), but I don't know what else to suggest -- except perhaps the
following: would that possible to transform the space (when in the CJ context)
into a zero-width space (ZWSP) to make it disappear in a natural/visual way?
Motivation: avoid complications in nsTextFrame, if possible.
(Assignee)

Comment 78

16 years ago
What rbs suggested is a interesting idea. But I am not sure how much it can do
to simplify the code.
I will mark this bug as fixed. File another bug anybody like to explore that idea.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 79

16 years ago
Mark as verified for this one.
Status: RESOLVED → VERIFIED

Comment 80

16 years ago
Bug 156369 is filed for remaining problems.

Comment 81

16 years ago
Adding adt1.0.1- per the adt.  Let's try to get it into the next release.
Keywords: adt1.0.1 → adt1.0.1-

Comment 82

16 years ago
I'm not very familiar with the Mozilla source but if the macro IS_CJK_CHAR or
IS_CJ_CHAR in intl/unicharutil/util/nsUnicharUtils.h works like 
IS_HIGH/LOW_SURROGATE, won't Chinese and Japanese characters composed of two
surrogates be missed and still cause this bug?


You need to log in before you can comment on or make changes to this bug.