In Windows Chrome and Mac Chrome, it's ok.  It seems that on Linux, 'mirroring' is not 
done 'automagically' ( http://unicode.org/reports/tr9/#Mirroring ). 

(No comment was entered for this change.)

This looks to be Linux only- ok on Mac (chromium 3.0.197.12 )

	Chrome.jpg 11.1 KB   View   Download

I can confirm this issue, and there is also related issue appears with the 
parentheses, it displayed in reverse direction when surrounding Arabic letters.
It works fine with Firefox.
see the attachment for more info.
Tested under Ubuntu 9.04 with Chromium 4.0.204.0 (Ubuntu build 24607)

	Chromium_parentheses.jpg 223 KB   View   Download

(No comment was entered for this change.)

 Issue 21367  has been merged into this issue.

if 21367 is a different issue, then please undupe

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

 Issue 30107  has been merged into this issue.

(No comment was entered for this change.)

Marking as untriaged for re-evaluation, since IMHO this is a pretty serious issue with 
bidi rendering on Linux.

 Issue 29763  has been merged into this issue.

(From the other bug, where I took a look at this.)

From this recent thread, it appears that Harfbuzz does not do mirroring for us.  :~(
http://lists.freedesktop.org/archives/harfbuzz/2010-January/000534.html

It is unlikely I will fix this anytime soon, but one can hope!

(No comment was entered for this change.)

Some observations:

- It's not that Linux Chrome never mirrors these characters.  Quite often it does, 
but not always when it should.

- Right now it seems to me that it forgets to mirror the paranthesis if the next 
strong directionality character is an Arabic (but not Hebrew!) letter.

Example: This html fragment:
<div dir=rtl>(1+2 &lt; 4)</div>
<div dir=rtl>(&#x05E9;: 1)</div>
<div dir=rtl>(&#x0644;: 1)</div>

is rendered as:
(4 > 1+2)           -- correct
(1: hebrewletter)   -- correct
(1: arabicletter(   -- incorrect

 Issue 29847  has been merged into this issue.

ummm, something like this must be fixed as soon as possible  

	Screenshot.png 38.0 KB   View   Download

The rest of that thread on the Harfbuzz mailing list says that mirroring is "part of 
the bidi algorithm, not the shaping, and harfbuzz doesn't do bidi":

http://lists.freedesktop.org/archives/harfbuzz/2010-January/000535.html

They suggest using GNU FriBidi for that:

http://lists.freedesktop.org/archives/harfbuzz/2010-January/000537.html

Would that be a possibility for Chrome?

I believe WebKit must already have an implementation of the bidi algorithm, since it 
does most of the text layout already.  I have a vague memory of some "mirror" flag 
being passed into some text-related functions, which I would hope is when WebKit has 
already computed whether we should mirror the mirrorable bits of a given span of 
characters.  If that is the case, fixing this should be a very small (like five lines, 
just an ICU call) amount of code.  A reduced test case (the simplest possible HTML 
page that contains some text that renders wrong and how it ought to render) would be a 
good place to help out if you wanted to.

I'm attaching ar_test.html as a very, very small test case.

Hopefully a screenshot is not needed, because it's very obvious which way the
parenthesis are supposed to be.

<div>
نص (عربي) بأقواس
</div>

ar_test.html 45 bytes   View   Download

Or this test which cover almost all the problem ..

with 2 cases, LTR and RTL

	ar_ltr.png 8.5 KB   View   Download

	ar_rtl.png 3.9 KB   View   Download

ar_test.html 196 bytes   Download

I have the same problem with parentheses too and another problem related to RTL but not sure if it is related to the same bug. As you can see in the attached picture an Arabic paragraph inside a table did not honer the dir="rtl" attribute and the alinement's remained left, however, Chrome under Windows and Firefox (under Linux and Windows) rendered the page correctly. This happens if there is a style to justify the text (style="text-align: justify;") if i remove that style it will render correctly.

the link to that page: http://fadvisor.net/blog/2010/03/auto-pilot/

Try the following html code (works fine with Firefox but not Chrome):

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body>
<table><tr><td style="text-align: justify;" dir="rtl">اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع اختبار العربي في قووقل كروم على نظام لينكس الرائع </td></tr></table>
</body></html>

	Chrome_RTL_Bug.png 167 KB   View   Download

I did a bit investigation on this.

The reason why parenthesis etc. bidi mirror characters are displayed correctly in Hebrew context is because most Hebrew characters are *not* complex script (please refer Font::CodePath Font::codePath(const TextRun& run) const for detail). So, they falls in Font::drawSimpleText() path. In which, the bidi mirror character is mirrored by mirroredChar(c) in Font::glyphDataForCharacter().

Following is the call stack:
        chrome.dll!WebCore::Font::glyphDataForCharacter(int c=0x00000029, bool m
irror=true, bool forceSmallCaps=false)  Line 60 C++
        chrome.dll!WebCore::WidthIterator::advance(int offset=0x00000004, WebCor
e::GlyphBuffer * glyphBuffer=0x05ad71e8)  Line 123 + 0x19 bytes C++
        chrome.dll!WebCore::Font::drawSimpleText(WebCore::GraphicsContext * cont
ext=0x05adf388, const WebCore::TextRun & run={...}, const WebCore::FloatPoint &
point={...}, int from=0x00000000, int to=0x00000004)  Line 265  C++
        chrome.dll!WebCore::Font::drawText(WebCore::GraphicsContext * context=0x
05adf388, const WebCore::TextRun & run={...}, const WebCore::FloatPoint & point=
{...}, int from=0x00000000, int to=0x00000004)  Line 156 + 0x1c bytes   C++
.......

Some Hebrew characters are considered as complex script (for example, U+05c6). So, the bidi mirror characters are not mirrored correctly for them.
You can try the following in Linux: <div>&#x05c6(&#x05c6)</div>

Most Arabic characters are considered as complext script. They are drawn by 
Font::drawComplexText(), in which, nothing is done on mirroring those characters.

I am not sure whether Chromium should take care of mirroring, maybe when construct TextRunWalker, when setting "m_item.string = m_run.characters()", iterate the character and mirror those having bidi_mirror property when m_run.rtl() is true?

Or harfbuzz has mirrored glyph information in font's glyph properties table and we should use it (correctly)?
Also, if harfbuzz does mirroring for some case, we need to figure it out to avoid double mirroring. 

(No comment was entered for this change.)

upstream:
https://bugs.webkit.org/show_bug.cgi?id=41305

(No comment was entered for this change.)

I also tried the url and experience the same thing. My build is chromium 6.0.457.0 (0) on Fedora 13. 

This is now fixed upstream (thanks xji!) and will show up in Chrome in a week or two.

Verified the issue on Dogfood device - 

Chromium OS	0.8.57.0 (Continuous Build 92d3779d - Builder: 888)
Chromium	6.0.472.0 (Developer Build 53024)

	screenshot-20100720-105533.png 658 KB   View   Download

	screenshot-20100720-105537.png 195 KB   View   Download

:) i have "chromium 5.0.375.125-1" on my Archlinux machine. The fix is in Chromium	6.0.472.0.
What you think how many years i have to wait?

Kind regards

Verified on Chrome 6.0.472 / Linux.

Parentheses appear as expected.

When in italic, parentheses tilt in the same direction as letters. This means that actually the counterpart glyph is printed, rather than mirroring the given glyph. Common sense tells me this is the correct behavior, and this is what FF3.6/Linux does.

When copy-pasting, the original codepoint is copied to the buffer, not the mirrored counterpart. Yet again correct.

Score: 3/3. Hooray! Thanks very much everyone!

Sia.Nariman: You can download the "dev channel" from http://dev.chromium.org/getting-involved/dev-channel to get the fix right now (even though it's an unstable release with all its possible gotchas). I don't know when 6.0.x will be stable and when it'll appear on your Archlinux box.

Build: 3.0.196.0 (Developer Build 21980)
   OS: Ubuntu 8.04 64-bit

Other Browsers:
Webkit nightly: N/A
    Firefox3.5: OK
           IE8: N/A

Steps:
1. Launch Chrome on Linux
2. Go to page http://www.google.com/intl/ar/
3. Click the down arrow on this page
4. Observe the even more icon ">>"

Result:
The direction of the even more icon ">>" turns to right on Arabic page

Expected:
The direction of the even more icon should turn to left

Notes:
OK on Windows