Tested 4-07-11-99 Win32 and Mac build.
After you visit the above page and hit the reload button, the chinese character is displayed fine but
the rest of the page are displayed as squares.
Same thing happens in http://warp/employees/erik/tests/forms/nbsp/all-charsets/gb2312.cgi page.
*** This bug has been marked as a duplicate of 4674 ***
I tested this page in 4-8-10 Win32 and Mac build. Chinese characters are displayed fine in MAC build.
In Win32 build, the last of 4 Chinese characters is not displayed correctly. I will reopen this and changed the
platform to PC.
I reassing this bug to Erik.
some Chinese glyph is missing. i think this is because the font we used to
render CJK Ideographs does not contains all the CJK ideographs glyph. change the
target to M5 and clear the duplicate
I tried this on US-NT4 running 4/13 build.
The forms widgets do not display Chinese, but the non-form text next to the check box and radio
buttons render correctly. Looks like a forms widget problem.
Dup of http://bugzilla.mozilla.org/show_bug.cgi?id=3962?
Chris, I think the problem here might be that we are using the native widgets
(from the OS) for HTML forms. Are there any plans to switch to GFX-based
widgets for forms? Our GFX can handle Unicode, but native widgets often cannot.
Teruko, Does this happen with any non-Latin1 pages? If so, please change
Teruko, Are the non-Latin1 display in form widgets problem only on Windows?
Moving to M6 and reassigning to Pierre who is taking over gfx form controls
execept buttons (owned by Eric Vaughan). GFX form controls can be toggled in
viewer and apprunner. They are not bug free. Text fields and text areas will not
be gfx based until Ender is hooked up.
i18n issue: reassigned to ftang
Franck, could you check whether this happens with the GFX form controls?
If only the native controls show the problem, we can close the bug as Invalid or
WontFix, unless you know how to display Chinese characters inside native Mac
I think the first thing we need to know is do we plan to switch OFF the native
widgets to GFX based and when ?
1. <INPUT type=button> -> Swtich to GFX base? When (M?)
2. single <SELECT> / <OPTION> -> Swtich to GFX base? When (M?)
3. multipel <SELECT> / <OPTION> -> Swtich to GFX base? When (M?)
4. <INPUT type=text> -> Swtich to ENDER? When (M?)
5. <TEXTAREA> -> Swtich to ENDER? When (M?)
6. <INPUT type=file> -> Swtich to GFX base? When (M?)
7. <INPUT type=readonly> -> Swtich to GFX base? When (M?)
6. <INPUT type=reset> -> Swtich to GFX base? When (M?)
7. <INPUT type=submit> -> Swtich to GFX base? When (M?)
If you plan to switch all of them to the GFX based control, then the bug will be
fixed the date you switch to the GFX/ENDER one. Otherwise, you should find a way
to render Unicode in those widget. (for example, draw the button by yourself.
Write a MDEF/LDEF as I did in 3.0). Yes, it is a lot of work, that is why
I suggest (to rods) we switch to the GFX based control last Oct.
reassign this back to pierre since pierre hold the decision of switching to GFX
Per discussion with ftang, I confirm that native widgets will not support asian
character sets. There is no defined date yet as to when we will switch to gfx
widgets. Please note that it's a global switch: we can't have some form controls
displayed as native widgets and other ones as gfx widgets.
Gfx widgets can be tested (for what it's worth in their current form) with
- launch Viewer
- under the Debug menu, select "GFX Widgets Mode"
- quit the app
- launch the app again
Moving to M15 all the bugs that have a dependancy on GFX widgets and/or Ender.
I tried this with 1999-06-08-08-M7 on Win95.
I enabled GFX forms widgets (except for text and textarea) by setting the pref:
Except for the text and textareas, all other widgets seem to display Chinese
input types: button, checkbox, radio, reset, submit
Should this be moved back to M10, since buster plans to change the text widgets
to default to GFX in early M10?
Reassigned to buster who owns gfx text widgets (the other widgets work fine).
set to M10. When gfx text controls are turned on, this will be fixed. somebody
in I18N could test this by manually turning gfx text controls if they wanted to.
moved to M11
I tested this in 9-10 Win32, Mac, and Linux builds. This page is displayed correctly in Win32 and Linux build without turning
on the GFX wiget in pref.js.
fixed for gfx text controls.
I verified this in 9-24-08 Mac build.