On my linux, it use the 10646 font from the fot server to display arabic page. we display the zwsp as [zwsp] in the text. We may have more problem with the following code points: cp1256 windows arabic 0x9d zwnj 0x9e zwj 0xfd lrzwmk oxfe rlzwmk cp1255 windows hebrew 0xfd lrzwmk oxfe rlzwmk

not quite sure where are these zwsp (U+200B) come from . Could be generated from ICU's arabic shapper.

to reproduce this, you need to first take the ISO10646 font fix in bug 116136

the reason it depend on 116136 is we need ISO10646 support to use with Arabic font.

bstell, can you r= this one ?

*** Bug 115229 has been marked as a duplicate of this bug. ***

Since this already has a patch, I have duped bug 115229 to here and not vice versa, and will repeat my comment from there: >See http://bugzilla.mozilla.org/show_bug.cgi?id=75026#c34 and >http://lxr.mozilla.org/mozilla/source/intl/unicharutil/src/nsBidiUtilsImp.cpp#410 >The zero-width space character is added in Arabic shaping to prevent problems >that were caused when the shaped buffer was smaller than the original. If it >appears as a renderable glyph in some fonts, we need to find a way to remove it >without regressing bug 75026. I think we should hold off on this patch for the time being, because a correct solution for the bugs listed in bug 115705 should remove this problem anyway.

reassign to ftang

I don't see specific details in bug 115705 . ok, I will hold this patch.

This bug is marked as depending on bug 116136. Can/have we verified this by turning off AASB? To verify this would someone disable AASB by changing this line in the unix.js file by to false: pref("font.scale.aa_bitmap.enable", true);

I modified unix.js as suggested, but the problem did not go away. Using Linux trunk build 2002-01-27-06.

Since the conversion happens before the drawing is done it looks to me like the code in attachment 62822 [details] [diff] [review] removes the chars from the data before they can be used for shaping. Is this right?

No, I don't think so. The shaping should have already been performed before any calls to GetWidth or DrawString, and control characters taken into account. Currently it isn't always, which is what the dependencies of bug 115705 are about.

push this to m1.1 and give to shanjian

accept.

*** Bug 141496 has been marked as a duplicate of this bug. ***

reassign to simon, he is more familiar with the problem.

In fact, the fix for this is trivial, as long as it isn't checked in until after bug 138097.

Comment on attachment 82564 [details] [diff] [review] Fix r=ftang. It is right. This is exactly the way I wrote it several years ago in the nsFontMetricsWin.cpp

Comment on attachment 82564 [details] [diff] [review] Fix >Index: content/shared/src/nsBidiUtils.cpp >=================================================================== >RCS file: /cvsroot/mozilla/content/shared/src/nsBidiUtils.cpp,v >retrieving revision 3.1 >diff -u -r3.1 nsBidiUtils.cpp >--- content/shared/src/nsBidiUtils.cpp 19 Feb 2002 20:41:02 -0000 3.1 >+++ content/shared/src/nsBidiUtils.cpp 18 Apr 2002 20:02:06 -0000 >@@ -289,7 +289,6 @@ > for(i=0;i<8;i++) { > if(key == gArabicLigatureMap[i]) { > done = PR_TRUE; >- *lDest++ = 0x200B;//ZERO WIDTH SPACE > *lDest++ = 0xFEF5 + i; > lSrc+=2; Do you still want to increment lSrc by two? If so, please explain why.

We are mapping two characters in the source, lam and alef, to one lam-alef ligature in the output, so |lSrc+=2| is correct. (Being wise after the event is always easier: in my first version I thought exactly the same as you and changed it to increment by 1, with the result that an extra alef character appeared after each lam-alef)

Comment on attachment 82564 [details] [diff] [review] Fix sr=waterson. a comment to that effect would be nice. :-)

Checked in to trunk.