136877 - vietnamese characters display ugly in html form

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Stefan Probst]

See the test page at http://www.isoc-vn.org/www/standard/browsertest51.html
Tested Mozilla: Version 0.9.9, build 2002031104
Affected OSes: Win98, Win98SE, WinME, probably also Win95.

Following issues:

1. Standard Display and Printing Test
Passed very well :)

2. Page "title" Tag Test
Mozilla does not detect that MS Windows cannot display the "special" Vietnamese
characters in the window title and at the bottom in the task bar. The result is,
that an ugly question mark ("?") is showed instead.

IE detects the problem and shows instead the file name. A poor compromise.

For Vietnamese, it would be possible to "reduce" the string to a purely ASCII -
or 8-bit version. Incorrect Vietnamese, but usually legible.

Alternative would be, to introduce a special "alt" parameter for the title tag ;)

3. Other Tags Test
Test 3a): No problem.
Test 3b): Mozilla does not show the image's "alt" parameter on mouse-over.
          IE does. Not a bug, but IMO a missing feature.
Test 3c): Ugly rendering of the link's "title" parameter.
          The "special e" is too close to the "i" in the example.
Test 3d): Ugly rendering of the acronym's "title" parameter.
          Same problem like in 3c)

4. Form Fields Test
In all three cases (Text Field, Select Field, Button) the text is ugly rendered.
Same like in 3c) above.
Pull the Select Field, and you'll see more examples of that poor rendering (even
if not that severe).
I have screen shots, if needed.

Cheers,
Stefan

Comment 1

[Stefan Probst]

Attachment: poor rendering in form fields and button

Comment 2

[Stefan Probst]

Attachment: question mark in window title

Comment 3

[Stefan Probst]

One solution regarding the window title (and a better one than only showing the
file name like IE):
If the OS cannot handle Unicode in the window title: Decompose the content of
the HTML head "title tag" into NFD (Unicode Normalization Form "D").
If the base character is "8-bit" only, then show that one and drop all the
modifiers. This works for Vietnamese, and might work for some other languages.

Stefan

PS: I forgot to write, that this all is about Unicode. But the given URL should
make this clear anyway.

Comment 4

[Yuying Long]

There are 2 problem here:
1. Display ? in window title - it's true but I'm afraid it's a same problem as
bug 97671, unless can reproduce it on native Vietnam windows. 
2. Ugly display on in form and button - it's display not bad on my WinXP, I
might wrong but I assume it's only on Windows9.x and ME, not on Win2000 and XP.

Confirm as new.

Comment 5

[Yuying Long]

Attachment: Display on WinXP in form and button

You can see they are displayed OK.

Comment 6

[Frank Tang]

let's focus this bug on the form issue. we have a seperate bug 97671 
about the title issue. add you comment about the title issue to that bug. 

about the form issue, I see the same thing on my winxp neither on my WinNT4 JA
system. 
Change the subject to "vietnamese characters display ugly in html form"
This could be a win95/98/me only issue. I think it is related to the font.

one suggestion, Stefan: can you try to change your window font setting and see
what will happen (you may need to relaunch mozilla each time you change it.)

Comment 7

[Stefan Probst]

1. I agree to split the bug report. Let's only concentrate on the rendering in
the forms. Regarding the window title, It seems actually more to be 9449. I
thought that I had searched for duplicates before :(.

2. In your screenshot about the Display on WinXP, in the text field, the dot
below the ê (e circumflex) is missing. I have only Win2k here (no XP), and it is
OK there. Might be also because of the font.
I have however a similar effect with the image's "alt" parameter: Although the
image "box" is large enough, the dot is not rendered, obviously because of a too
large free space between image border and text box. When I reduce the text size
to 90%, then the dot appears. IE uses a smaller font size for the images alt
parameter and has therefore no problem. Pls. advise, whether to file a separate
bug for this.

3. We are using very "normal" International/US Windows versions here. No special
font setting at all. The MS VN-Windows is unusable. You should be able to
reproduce everything on your own machines - as long as same OS version.

4. Yes, the ugly rendering affects only pre-Win2k, as I wrote. Here the results
on my WinME:
For the image's "alt" parameter IE uses another, small font and has problems.
Mozilla seems to use the normal screen font and has no problem.
For the text field and the button, IE uses the normal screen font and has no
problem. Mozilla seems to use here (and in all the other instances) a smaller
(or even another?) font and has problems.

Once you have reproduced the problem, could you try to just increase the font
size on pre-Win2k a bit for all the instances (except the image "alt" parameter,
where it is ok already)?

Comment 8

[Stefan Probst]

First: I saw one more issue: the Bookmarks list in the menu is similarly
effected....

OK, I tried the Windows settings.

All fonts were set to MS Sans Serif (Western). I didn't mess around there.

When I change either the "Menu font" or "Selected Items font" from size 8 to
size 9 (or 10), then the Booksmarks are rendered ok.

When I change the "Message Box font" from size 8 to size 9 (or 10), then the
title parameter in the link tag and the acronym tag is rendered OK!!

The poor rendering in the form (text field, select field, button) can be solved
by increasing the font size - which creates even more problems. :(
When I set in Mozilla the font size (View-text zoom) to large values, then the
"title parameters" in the "image" and "acronym" tag stay small, because you take
the Windows parameter for the Message Box. IMHO, you shouldn't do this. In the
form, the rendering is ok then, but the size of the text field and select field
is not increased appropriately. Sometimes only the dot below is missing, in the
select box, only the upper part of the line is visible.

Comment 9

[Stefan Probst]

Sorry for piece meat ;)

Win2k uses "Tahoma 8" as standard menu font, not "MS Sans Serif" like my WinME.
If I set it here to "Tahoma 8", then the Bookmarks are ok under WinME.

I will tell Vietnamese developers to create a small idiot-proof tool to switch
menu fonts on pre-Win2k. I think, you can forget about the Bookmarks problem.

Comment 10

[Stefan Probst]

Good Evening,

one week has passed without progress.
May I set the target milestone to 1.0.1?

Right now, it looks like it is only an issue of using other fonts:

1. "title parameters" in the "image" and "acronym" tag:
Now: you use the Windows font parameter for the Message Box.
Bad: 1. Font too small, therefore ugly rendering.
     2. Font stays small, even if text is enlarged,
         e.g. for people with poor vision.
Better (i.e. change): Don't use the Windows setting, but e.g. the normal body
text font. Make sure, that it is at least font size 9 (for MS Sans Serif) or
font size 8 (for Tahoma).

2. in forms (text field, select field, button):
Increase the default font size a bit.
Make sure, that the text field and select field are large enough for the
characters, even if the user enlarges the fonts (poor vision).

Those two changes should solve all mentioned problems for VN Unicode Characters,
except
- window title (see the other bug)
- bookmark (which you probably can't solve without changing the Windows menu
font; it should be mentioned in the FAQs though.)

Have a nice weekend,
Stefan

Comment 11

[Roy Yokoyama]

font issue; assign to shanjian

Comment 12

[Frank Tang]

>May I set the target milestone to 1.0.1?
You are welcome to set to any mileston if you assign that bug to yourself and
propose the patch to fix that. Otherwise, leave that to the one who own that bug
please. 
As I state previously, if you use this bug report to track more than one thing-
then no one will look at it and fix any of them. Please only mention ONE problem
at one bug report. Different issue need to be assign to different person and
differrent patch will be proposed for different issue and different reviewer and
super review need to look at them seperately.

Comment 13

[Stefan Probst]

> Please only mention ONE problem at one bug report.
There was probably a misunderstanding.
I was mentioning everything from the beginning. You requested to split off the
window title issue, which was agreed. I thought everything else is the same.

Do you consider the font size
- in the "title" attribute of the "image" and "acronym" tag
- in forms (text field, select field, button)
as two different issues?

Stefan

Comment 14

[Stefan Probst]

Frank,

should I split the bug?

> Do you consider the font size
> - in the "title" attribute of the "image" and "acronym" tag
> - in forms (text field, select field, button)
> as two different issues?

Stefan

Comment 15

[Stefan Probst]

Good Morning,

sorry to bother everybody again....

I just saw that version 1.0 is released.
I will release a "all in one" CD-ROM within about two weeks, containing free
(Free SW and Freeware) SW for Vietnamese-Unicode:
Mozilla, OpenOffice, some Keyboard Drivers, JRE, ...
It looks like the government is interested to have one CD, which they could
distribute to ther offices......

I would love to have a Mozilla version included, which handles the Unicode fonts
better. Do you think, you can get that one fixed within one or two weeks:

> 2. in forms (text field, select field, button):
> Increase the default font size a bit.
> Make sure, that the text field and select field are large enough for the
> characters, even if the user enlarges the fonts (poor vision).

My latest test page is http://www.isoc-vn.org/www/standard/browsertest52.html
Can I do anything to help you / make it easier?

Regards, and Happy Birthday Mozilla!
Thanks to all of you!

Stefan

Comment 16

[Frank Tang]

shanjian is no longer working on mozilla for 2 years and these bugs are still
here. Mark them won't fix. If you want to reopen it, find a good owner first. 

Comment 17

[Travis Chase]

Mass Re-open of Frank Tangs Won't fix debacle. Spam is his responsibility not my own

Comment 18

[Travis Chase]

Mass Re-assinging Frank Tangs old bugs that he closed won't fix and had to be
re-open. Spam is his fault not my own

Comment 19

[Zibi Braniecki [:zbraniecki][:gandalf]]

This looks good now!