15989 - Text describing images before they load is reversed

Status: VERIFIED DUPLICATE of bug 29498

(Core :: Layout, defect, P3)

Description

[moshev]

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 :),....)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 2

[moshev]

Attachment: The screenshot you requested

Comment 3

[moshev]

Attachment: Another one, even without <img> tag, it's M10 release BTW

Comment 4

[moshev]

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 :(

Comment 5

[moshev]

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?

Comment 6

[moshev]

Attachment: Another one, in editor

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 ™ in the Arial font, with the line split into two halves around
that character.  I'll look at the others too in a minute...

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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 [e-mail], author of Unix font selection code.

Comment 10

[moshev]

Attachment: Here's my XF86Config

Comment 11

[moshev]

Attachment: here's my /etc/X11/fs/config

Comment 12

[moshev]

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)

Comment 13

[Erik van der Poel]

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

Comment 14

[troy]

I think this is a gfx rendering problem.

Kevin, who owns the gfx specific rendering code? And what is the component?

Comment 15

[Kevin McCluskey (gone)]

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.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 17

[Ramiro Estrugo]

waqar: this needs more investigation, it might be a layout or more likely i18n
bug.

erik can help with i18n issues on unix.

Comment 18

[leger]

Resetting QA contact from leger.

Comment 19

[waqar]

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

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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...

Comment 22

[moshev]

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.

Comment 23

[Erik van der Poel]

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

Comment 24

[Erik van der Poel]

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

Comment 25

[cpratt]

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.

Comment 26

[moshev]

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???

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on 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.

Comment 28

[cpratt]

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

Comment 29

[Frank Tang]

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. 

Comment 30

[Tomer Brisker]

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.

Comment 31

[Frank Tang]

dup of 29498. Will fix tonight.

*** This bug has been marked as a duplicate of 29498 ***

Comment 32

[Sebastian Späth]

VERIFY dupe