When you load a page with <img src></img> tag, that have a textual description for image (the text appearing before the image loads), the text appears in revers order while the image loads (xuniL) for Linux (While it's good for BiDi support :),....)

Changing to Layout, for now, anyway. I'm not seeing this on Linux viewer 1999-10-08-08-M11. Could there be some detail of your system configuration (bidi support?) causing this? What build are you using? Could you attach a screenshot?

Attached two screenshots as requested, The build is 1999100808 it's m10 release, (I wish i had BiDi on linux, there is however none available :(

Forgot this one, it's a mixed RH/Mandrake 6.0-1 with glibc2.1, and Linux 2.2.5 What dependencies do you want me to check?

I'm not seeing this in the M10 release. I can also see from the second screenshot that you're not seeing bug 12217 and I am. What font server are you using? I use xfs with xfsft built into it (which is what comes with RH 6.0), with some TT fonts added.

I think the reason I'm not seeing the bug is that I see bug 12217 and you don't. The problems of RTL text in your second screenshot all occur around the character &#153; in the Arial font, with the line split into two halves around that character. I'll look at the others too in a minute...

There's no such pattern on the other examples, so only the second example makes some degree of sense to me. I have to say this looks more like some sort of an i18n/font handling bug. cc:ing erik@netscape.com, author of Unix font selection code.

I am not sure how to test for the font server, i onced installed xfs/xftt, but the override it with RH 6 upgrade, so now i am not sure what's running, in "ps axw" I don't see it. Tell me if you need any other info from my system. (like some specific fonts or output of xlsfonts)

Frank, any ideas? (The text is being reversed.)

I think this is a gfx rendering problem. Kevin, who owns the gfx specific rendering code? And what is the component?

My guess is the problem is in the nsRenderingContextGTK::DrawString. There is code which will render the string one character at a time, by placing the coordinates of the character through a transform. It's possible that the transform is reflecting the coordinates, S_IMETHODIMP nsRenderingContextGTK::DrawString(const char *aString, PRUint32 aLength, nscoord aX, nscoord aY, const nscoord* aSpacing) ... if (nsnull != aSpacing) { // Render the string, one character at a time... const char* end = aString + aLength; while (aString < end) { char ch = *aString++; nscoord xx = x; nscoord yy = y; mTMatrix->TransformCoord(&xx, &yy); ::gdk_draw_text(mSurface->GetDrawable(), mCurrentFont, mSurface->GetGC(), xx, yy, &ch, 1); x += *aSpacing++; } Ramiro and Pavlov own the nsRenderingContextGTK component, but it may be XPCODE thats to blame for messing up the tranform.

It doesn't really look like a transform bug, because the letter-spacing is not messed up (unless the transform would also cause it to position by the other edge of the letter). And also, could a transform cause the two halves of the sentence to be split, like the third line from the end in attachment 2061 [details], which is shown like: ABCDEFG LKJIHNM OPQRSTU? It really does look more like an i18n bug.

waqar: this needs more investigation, it might be a layout or more likely i18n bug. erik can help with i18n issues on unix.

Resetting QA contact from leger.

I am not seen this happen as well. I am going to close this as works for me.

I think that's a bad idea. There's some font bug that's preventing the right font from showing. When that font is visible, I think the bug will show up. A bug should be filed on the fonts showing up without Arial...

Actually, the font thing is a residual style bug. So how did it work before? Could the original reporter of this bug comment? If you still see the bug, could you make a simplified test case? Could you figure out which font on your system is being used? Could your Arial font be a different version (a Hebrew version from Microsoft)? Please don't verify this bug yet. I think it could be something system-specific...

I originally had TTF's from Hebrew version of MS Windows, but lately i played a lot with the fonts on my system, and no i don't see it anymore, but i think the bug is still there, cause before i played with fonts i had this problem on almost any page i visited. I think it should be left open untill font-preferences are working, then i could try it with different fonts on my system and tell if it's still there with some fonts.

Adding dependency on 8801 (font prefs). Re-opening.

Frank, you added some bidi hacks to Unix gfx. Could you double-check this?

I've come across what I believe may be another issue caused by the same root problem as described in this bug report. If you view the page at: http://www.unicode.org/iuc/iuc10/x-utf8.html you'll see that there is a section in Hebrew (ignore the Yiddish one). In this section, there are a few words that aren't in Hebrew. However, these are incorrectly rendered RTL instead of LTR. For example, '1997' is rendered as '7991'. Therefore, I'm thinking that this would be ultimately a similar example of the problem reported in this bug. Right? If not, please let me know directly so that I may file a new bug.

When i saw the problem i saw exactly what you describe on many hebrew pages, so i think it's the same problem. Now, i don't see the problem including on the page you are reffering to, however the hebrew words on this page are displayed in incorrect order. I am not sure if this is because this page's layout is logical. If it is, then it is strange that mozilla is able to correctly reverse the letters inside the words, is there anyone that implemented a partial RTL-LTR for mozilla???

The problem cpratt described sounds like a separate bug. This bug should be for creation of RTL text within an entirely LTR document due to the presence of RTL fonts.

Bug 21022 now contains the problem I described in an earlier comment. My apologies for the intrusion!

What happen is the following- moshev have the following line in his XF86config (id=2066) FontPath "/usr/X11R6/lib/X11/fonts/hebrew" Therefore, he have a hebrew font in his font path. Somehow the img fallback code use the hebrew font. In the hebrew font hack I add to gfx, I assume the hebrew font won't be in the first item of the font list and just assume all the ASCII character will be handle by non Hewbrew/Arabic fonts. Therefore, I revere everything. One quick and dirty way to solve it is to clear the bits in the 8K bits array for the hebrew/Arabic fonts.

I am having this same problem with M13 under linux. I have some hebrew fonts installed, but thanks to the font-prefs problem i can't find which one exactly causes the problem and remove it. I know however the "bible" font is the one which font-prefs picks by default on my system. getting new 13G hd soon so i might be able to build a new mozilla with the font-prefs bug fix soon (a bit too short on disk space right now). One thing i notice is that this reverses any line cotaining high-ascii chars on it which can be quite annoying, therefor i suggest fixing this earlier then M17, since right now i have to open netscape 4.7 whenever i view a a page with more then 2 or 3 lines containing high ascii.

dup of 29498. Will fix tonight. *** This bug has been marked as a duplicate of 29498 ***

VERIFY dupe