When rendering TextFrames, Windows uses PaintUnicodeText, but Linux uses PaintAsciiText. Pavlov says he implemented the unicode stuff, but we aren't using it; apparently Linux still isn't claiming multibyte capability. This happens because nsTextTransformer::HasMultibyte() returns false for Linux and true for Windows. That's as far as I've traced it.

Inserting Milestone info.

Setting all current Open/Normal to M4.

pavlov, does GDK plan to support Unicode drawing on ::gdk_draw_text ? IF not, then we probably should implement the unicode drawing (need multiple font and Unicode converter) and call X lib directly. Also, is ::gdk_draw_text depend on the limited ANSI/ISO C (also X ) gobal locale which prevent us draw Japanese on Korena locale ? We should not depend on such thing for rendering since web base application have higher chance to render data which is not in local locale. Local locale model break in such case.

I think Owen might have answer for this.

I think Owen might have answer for this.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

marking all non-functionality m4 bugs of mine to m5 as i won't be around for the next week or two.

Pavlov, hope you don't mind that I re-assigned to myself. This is what I'm working on now...

Bookeeping: Moved from M5 to M4 since its already fixed.

Fixed in April 23rd Build.