Closed Bug 29498 Opened 25 years ago Closed 25 years ago

Left-to-right characters are drawn in the wrong order if the element contains one or more right-to-left characters (M13)

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: b.greiner, Assigned: ftang)

References

(
URL
)

Details

Steps to reproduce the bug: 1) Create an HTML page with an element that contains both rtl and ltr characters. 2) View the page. 3) Mozilla now draws the RTL content correctly, but refuses to "turn around again" the LTR content, thus rendering it backwards. i.e. "Mozilla" becomes "allizoM". I have created a sample web page, see URL. This bug also occurs in the International Smoke Tests #14 and #15 (see the Hebrew and Arabic sections). In case this bug is caused by my true-type fonts: I use the Unicode 2 font that comes with MS Office 2000 to display all non-Latin characters.
Reassigning to Kipp's bug list
Assignee: troy → kipp
mine
Assignee: kipp → buster
There was a similar bug with problems like this on Linux, with Hebrew fonts. Should this go to the Internationalization team?
reassigning to erik, who is looking at that part of the code. Erik, if this isn't your bug, please reassign back to me.
Assignee: buster → erik
Frank, this is due to your check-in(s). Is this a Beta 1 candidate?
Assignee: erik → ftang
Please remember to mark unconfirmed bugs as new. You talking beta1 but this bug hasn't even been confirmed?!
Status: UNCONFIRMED → NEW
Ever confirmed: true
no not beta1
Status: NEW → ASSIGNED
reassign to bobj- this is block by bi-di planning.
Assignee: ftang → bobj
Status: ASSIGNED → NEW
reassign to bi-di owner.
Assignee: bobj → mkaply
Assignee: mkaply → ftang
Target Milestone: M15
Frank, the non-RTL text is being drawn RTL because of your quick hack. Please remove your quick hack. I think this should be fixed before M15.
erik is right. I will do that tonight. I will remove my Linux and window hack. Here is the diff I will check in. mkaply- please aware about the existing of this hack and how to turn it back in case you WANT to use these code. Feel free to improve / remove them to make the real bi-di work. :) We have the following problems on the Win/Linux hebrew/arabic reordering code 1. it assume the upper layer already resoulve bi-di and call GetWidth and DrawString with uni direction. (either LTR or RTL) 2. It assume the LTR text never render with a RTL font It simply draw the text from right to left if the font contains hewbrew glyph The same problem in window's Arabic shaping code, plus, the shaping code is not complete . There are some bug in there. The basic shaping is ok, but combining mark is not complete. Also, the Lam Alef ligurature may not work 100% correctly. It is simply my one night hack. Also, some of the Arabic characters are render form left to right, (for example, digits), we currently render them as from right to left. This is due to the same assumption that upper level will resolve the bi-di before calling it. Do not turn these code back unless you resolve the first 2 issue. Otherwise, it may cause problem on non Hebrew/Arabic page on a system which have those fonts.
Status: NEW → ASSIGNED
Here is the diff for the linux part I will check in tonight. Index: gtk/nsFontMetricsGTK.cpp =================================================================== RCS file: /m/pub/mozilla/gfx/src/gtk/nsFontMetricsGTK.cpp,v retrieving revision 1.76 diff -c -r1.76 nsFontMetricsGTK.cpp *** nsFontMetricsGTK.cpp 2000/02/12 22:17:15 1.76 --- nsFontMetricsGTK.cpp 2000/03/13 19:09:42 *************** *** 972,977 **** --- 972,982 ---- } } + // the following code assume all the PRUnichar is draw in the same + // direction- left to right, without mixing with characters which should + // draw from right to left. This mean it should not be used untill the + // upper level code resolve bi-di and ensure this assumption. otherwise + // it may break non-bidi pages on a system which have hebrew/arabic fonts static gint SingleByteConvertReverse(nsFontCharSetInfo* aSelf, const PRUnichar* aSrcBuf, PRInt32 aSrcLen, char* aDestBuf, PRInt32 aDestLen) *************** *** 1069,1075 **** static nsFontCharSetInfo ISO88597 = { "ISO-8859-7", SingleByteConvert, 0 }; static nsFontCharSetInfo ISO88598 = ! { "ISO-8859-8", SingleByteConvertReverse, 0 }; static nsFontCharSetInfo ISO88599 = { "ISO-8859-9", SingleByteConvert, 0 }; static nsFontCharSetInfo ISO885915 = --- 1074,1083 ---- static nsFontCharSetInfo ISO88597 = { "ISO-8859-7", SingleByteConvert, 0 }; static nsFontCharSetInfo ISO88598 = ! { "ISO-8859-8", SingleByteConvert, 0 }; ! // change from ! // { "ISO-8859-8", SingleByteConvertReverse, 0 }; ! // untill we fix the layout and ensure we only call this with pure RTL text static nsFontCharSetInfo ISO88599 = { "ISO-8859-9", SingleByteConvert, 0 }; static nsFontCharSetInfo ISO885915 =
Here is the code that I will check in to remove the buggy bi-di hack I check in several monthes ago. Index: nsRenderingContextWin.cpp =================================================================== RCS file: /m/pub/mozilla/gfx/src/windows/nsRenderingContextWin.cpp,v retrieving revision 3.100 diff -c -r3.100 nsRenderingContextWin.cpp *** nsRenderingContextWin.cpp 2000/03/11 07:49:08 3.100 --- nsRenderingContextWin.cpp 2000/03/13 19:22:36 *************** *** 45,51 **** #define VERIFY(exp) (exp) #endif // !_DEBUG ! #define ARABIC_HEBREW_RENDERING static NS_DEFINE_IID(kIRenderingContextIID, NS_IRENDERING_CONTEXT_IID); static NS_DEFINE_IID(kIRenderingContextWinIID, NS_IRENDERING_CONTEXT_WIN_IID); --- 45,53 ---- #define VERIFY(exp) (exp) #endif // !_DEBUG ! //comment this out so we won't do arabic and hebrew buggy reordering untill ! // it get fixed ! //#define ARABIC_HEBREW_RENDERING static NS_DEFINE_IID(kIRenderingContextIID, NS_IRENDERING_CONTEXT_IID); static NS_DEFINE_IID(kIRenderingContextWinIID, NS_IRENDERING_CONTEXT_WIN_IID); *************** *** 1396,1401 **** --- 1398,1405 ---- #define HAS_ARABIC_PRESENTATION_FORM_B(font) (FONT_HAS_GLYPH((font)->mMap, 0xFE81)) #define HAS_HEBREW_GLYPH(font) (FONT_HAS_GLYPH((font)->mMap, 0x05D0)) + // the following code assume all the aString is from right to left without + // mixing with left to right characters static void HebrewReordering(const PRUnichar *aString, PRUint32 aLen, PRUnichar* aBuf, PRUint32 &aBufLen) {
*** Bug 15989 has been marked as a duplicate of this bug. ***
Blocks: 31665
*** Bug 21022 has been marked as a duplicate of this bug. ***
fix check in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking verified in the July 14th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.