Closed Bug 97343 Opened 24 years ago Closed 24 years ago

Cannot display middot(Unicode 00B7)in the UI under W95/W98

Categories

(Core :: Internationalization, defect, P2)

Product:
Core
Component:
Internationalization
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: jmas, Assigned: shanjian)

References

(
URL
)

Details

(Keywords: intl, Whiteboard: need r/sr)

Attachments

(7 files)

UTF-8 HTML file with middle dots
271 bytes, text/html
Details
screenshot of HTML displaying middot on Win95
25.20 KB, image/jpeg
Details
test page which will force the problem surface by using font face tag on 95
54 bytes, text/html
Details
A complete test case which show all characters in 80-ff range
2.25 KB, text/html
Details
proposed patch
2.52 KB, patch
ftang
: review+
attinasi
: superreview+
Details | Diff | Splinter Review
test html file also failed on NT
2.99 KB, text/html
Details
screenshot on my NT4j
123.04 KB, image/jpeg
Details
From Bugzilla Helper: User-Agent: Mozilla/4.76 [ca] (Win95; U) BuildID: 2001062815 The middle dot character is largely used in the Catalan language, in words such as "il·lusió". This bug may also effect other characters but we cannot confirm it. We have used MozillaTranslator to create our Catalan Language pack. Under Windows 2000 and ME the words containing the middot character are displayed properly but under Windows 95 and 98 an invalid character not the middot character is displayed. Also, when you type the character in an edit box in the Mozilla UI, it won't appear correctly, however, if you cut and paste the contents of the edit box to another windows application it will appear properly. Text containing this character is displayed properly under all circumstances when it appears in an HTML page using UTF8 or ISO8859-1 encodings, but it will not appear correctly in the application UI, such as, the preference dialog. This bug is important because people under W95/W98 cannot see this character properly in the UI or when they type a word that contains the middot. Reproducible: Always Steps to Reproduce: 1.Load a Catalan Language pack (we can provide it) 2.Run Mozilla 3.Go to any UI element containing the middot character or enter the middot character in an edit box Actual Results: An invalid character is displayed Expected Results: Display the middot character
Netscape 4.76 has a very similar problem with an HTML page encoded using UTF8, it cannot display properly the middot character, but the same page will be displayed correctly under Mozilla 0.92. This 4.76 problem also only happens under Windows 95/98. I do not know if this can help. May be it was a bug that was fixed for the page display but not for the UI.
->i18n
Assignee: asa → yokoyama
Component: Browser-General → Internationalization
QA Contact: doronr → andreasb
Assigning to tao === cc'ing myself and ftang
Assignee: yokoyama → tao
i18n (rendering problem) -> i18n
Assignee: tao → yokoyama
Switching QA contact to ylong. Yuying, can you try and reproduce? Thanks.
Keywords: intl
QA Contact: andreasb → ylong
Reporter: Which version of Win98 are you using? I check it on Win98SE, it display the middot OK in Browser and Composer at least this "il·lusió" in your description. Also please provide the Catalan language of you are using, the URLs that contains middot.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
We cannot confirm that this bug happens in W98SE, we know for sure that it happens in W95 and W98 first edition. To reproducte the bug: 1. Install the English 0.92 Mozilla build (release version) 2. Download the Catalan XPI from: http://www.softcatala.org/~extern/ca.xpi (this language pack only works with 0.92 release) 3. Install the XPI (File->Open File) 4. Select the Catalan language Apperance->Language->Catala 5. Go to Preferences, avanaced, installation and you will see the problems. Have a look to this picture: http://www.softcatala.org/~extern/mozilla-middot.jpg We red circles indicate the places where the middot was supposed to be but we got an invalid char. Can you reproduce the problem? The problem only happens in the Mozilla UI, as far as we know, never in an HTML page.
=== assigning to ftang and cc'ing shanjian
Assignee: yokoyama → ftang
Hi, Frank: I was under the impression that Mozilla UI shares the same rendering engine as the HTML pages in the Browser's canvas area. Any idea what might cause the problem since we are able to display even CJK and BiDi characters properly in the UI? CC bobj & chris saari. Hi, Jordi: Does this problem happen on widgets other than tree, frame title, and checkbox text? For example, menuitems and command buttons?
Yes, it NOT only happens in the three control, it also happens in the static text box, checkboxes, and other controls. Take a look at this picture: http://www.softcatala.org/~extern/mozilla-middot.jpg We look at the code that draws the text and there are lots of plataform conditions, we belive that the bug is Thanks Tao, Jordi,
There are two possilbe cause of this bug 1. the middle dot (0xb7) is encoded incorrectly in the dtd file (dtd file should be encoed in UTF-8. U+00B7 should be encoded as two bytes sequence 0xc2 0xb7. To prove this is not the cause, replace your middle dot characters with "·" in dtd file or "\u00b7" in property file. If they display correctly, then the problem is the code point in your dtd or property file is wrong. Somehow I cannot unzip http://www.softcatala.org/~extern/ca.xpi with winzip, can you attach the dtd file to this bug report ? 2. the font used by the font engine have vertical bar for the U+00b7 position. to verify this is the problem or not, use the window's "Character Map" in the "Accessories" menu, select different font and find out which font have the vertical bar encoded in the 0xb7 position. Tell me the font name.
Status: NEW → ASSIGNED
Frank, 1. I have tried to remplace in our dtd the middot characters by "·" and we get the same result, an invalid charcter is displayed. I have uploaded to our site, a DTD file that uses the middot: http://www.softcatala.org/~extern/pref-themes.dtd 2. I have used the charmap.exe to look for a font with the invalid chat in the 0xb7 position in one of the machines with w95 but all the regular fonts seem to have the middot, except for symbol and other fonts used to represent only symbols. This problem only happens with w95 and w98, never under w2000 or me. We are not familiar with the Mozilla source code, but we have a look at the code to see if we were able to trace the problem and we got the impression that the bug may be in "nsFontMetricsWin.cpp". There are lots of "hacks" that are very plataform specific. I do not know if this can help. Thanks Tao! I looks to us that enconding is correct. It was generated by MozillaTranslator. 2.
Sorry, ignore the comments after "Thanks Tao!"
I created an HTML file with a middle dot and it looks displays fine on W95 using the commercial 9/20 build. So I don't think it has anything to do with the font subsystem. Here's the HTML (in UTF-8): ======================================= <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <title>UTF8 middot</title> </head> <body> UTF8 HTML file <br>ilÂ?lusi?? <br>il&#xb7;lusi?? </body> </html>
My build info: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.4) Gecko/20010920 Netscape6/6.2
Jordi: what does http://bugzilla.mozilla.org/showattachment.cgi?attach_id=50585 display on you system? Can you figure out from the surrounding text, which font face are used to display them ? Also, try the following, open Preference:Font, and select each encoding, and then click OK (Dont need to change any font), and look at that page again.
> what does http://bugzilla.mozilla.org/showattachment.cgi?attach_id=50585 > display on you system? That's the screenshot. I assume he meant the HTML page: http://bugzilla.mozilla.org/attachment.cgi?id=50583
We can see without problems the HTML file created by bobj@netscape.com. As I mention before, the problem does not occur when you render HTML files, they are displayed OK. The problem ocurrs when you used the middot character in the Mozilla's UI. That's the reason why I should have posted a DTD file. Have a look to this screen shot: http://www.softcatala.org/~extern/mozilla-middot.jpg You will see that the problem ocurrs in the Mozilla UI. I also only happens in Windows 98 and 95. Well, I just want to mention again: HTML pages display just fine the problem is when using the middot char in Mozilla's UI. We are using Mozilla release 0.92. I hope that this helps.
(ftang using bobj's account) does this only happen on "Classic" theme? Does it happen on "Modern" theme? It seems the problem is related to the font we used. In Classic theme, we sue the font which the "Display" control panel set to, which by default is "MS San Serif". I can reproduce this by using a html page.
the problem is the font name "MS Sans Serif" on Win95 and 98
I have been on holidays. Sorry for the delay. I do not think that this is a MS Sans Serif font problem under Windows 95 because: 1. MS Sans Serif is heavily used in many Windows applications under Windows 95 and 98 and they can display the middle dot character properly. 2. If I run Word, and type a text with the middle dot character and I select the MS Sans Serif font it's displayed properly. 3. I do have lots of applications translated into Catalan in my W95 machine and all of them display this character properly. 4. If I copy the font from a ME machine (in ME there is no problem), with the ME font I still have the same problem. I honestly think that this is a Mozilla's problem and it has to do with the way that it handles code. In the FE there is lots of code for font handle specific to Windows 95 and 98. I stronly believe that the problem can be there. Well, I do not know how we can help fixing this bug. What can we do next? I suggest that Frank or someone installs a copy of Mozilla with this problem to be able to trace and fix the problem. Thanks,
You misunderstand what I state here. I think the problem is the way mozilla (in gfx) handle bitmap font, especially like "MS Sans Serif" . I can reproduce similar issue on different code point on my NT. (not 00b7, but some other code point) mark it as m0.9.6 and reassign to shanjian Try the following URL- http://people.netscape.com/ftang/demo/ncr.cgi
Assignee: ftang → shanjian
URL: None → http://people.netscape.com/ftang/demo...
Status: ASSIGNED → NEW
Target Milestone: --- → mozilla0.9.6
Accepting.
Status: NEW → ASSIGNED
I wrote a small testing program on windows and play with this for a little while on win98. I found that some of the fonts on 98 (ms sans serif is one of it) does not work well with TextOutW. The same font works fine with TextOutA. In past, erik had to wrote a A-version font implementation to fixed a crash in japanese windows, and the crashing character is 0xb7. Using A-version of font metrics implementation is one solution. I would like to spend some time on this to see if there is a possible better solution.
I think this is a P2 bug. It is high priority.
Priority: -- → P2
With my test case, I tried all raster font on winNT and win98, here is a summary of my findings: . Winnt: "MS Sans Serif" and "MS Serif" has problem with 0x82 to 0x8c, 0x93 to 0x9c "Modern", "Courier", "Small Fonts", "Roman" and all truetype font are OK. . On Win98 , non-A-version "MS Sans Serif" and "MS Serif" has problem with 0x82 to 0x8c, 0x93 to 0x9c, 0xb7 "Modern", "Courier", "Small Fonts", "Roman" and all truetype font are OK. . On Win98, A-version All looks fine. Since 0x80 to 0x9f are left for C1 in 8859-x, the problem is not serious. 0xb7 is something we have to deal with. In Erik's existing code, charmap for certain charset is generated using system's conversion API. Only a character in certain charset can be converted to wchar, do we declare the support for such char in charmap.
Attached patch proposed patch — — Splinter Review
frank, I found an alternative approach to fix this problem without changing to A-version. In non-A-Version api, charmaps for charset are soly used for raster font. So I skipped 0xb7 when setting such charmap. That will let system resort to other fonts when rendering 0xb7. A more convervative approach might be to only leave 0xb7 unset for "MS Sans Serif" and "MS Serif", but that way we will have to do a string comparison when searching for charmap for each font, that will be too expensive. As long as oxb7 is rendered correctly, nobody can tell it is from a different font. You might also have noticed that 0x82 to 0x8c, 0x93 to 0x9c are untouched. IMO that is not worth fixing. If you have a differen opinion, we can certainly fix them in the same place with the same way.
Whiteboard: need r/sr
>You might also have noticed that 0x82 to 0x8c, 0x93 to 0x9c are untouched. >IMO that is not worth fixing. Why ? these seems important characters for some language too. Probably we need a different fix for it; I think we should not generate the multibyte by for loop from 0 to 255 (0xff). The origional definitation of ANSI charcter set from my Win3.1 and Win95 programming book show it does not contains the 0x80-0x9F part. see the following Page 130 (Figure 3-8. The ANSI character set arranged by character code.) of Programming Windows 3.1 3rd Edition, Charles Petzold, Microsoft Press, ISBN 1-55615-395-3 also see Page 281 (Figure 5-8. The ANSI character set arranged by character code.) of Programming Windows 95, Charles Petzold, Microsoft Press, ISBN 1-55615-676-6 Page 162 (Figure 3-8. The ANSI character set) of Programming Windows 95 with MFC, Jeff Prosise, Microsoft Press, ISBN 1-55615-902-1 I think your approach for B7 is needed. But I think we should also fix other characters. They might be used somewhere else. The unicode character of these char are: 0x80 0x20AC #EURO SIGN 0x82 0x201A #SINGLE LOW-9 QUOTATION MARK 0x83 0x0192 #LATIN SMALL LETTER F WITH HOOK 0x84 0x201E #DOUBLE LOW-9 QUOTATION MARK 0x85 0x2026 #HORIZONTAL ELLIPSIS 0x86 0x2020 #DAGGER 0x87 0x2021 #DOUBLE DAGGER 0x88 0x02C6 #MODIFIER LETTER CIRCUMFLEX ACCENT 0x89 0x2030 #PER MILLE SIGN 0x8A 0x0160 #LATIN CAPITAL LETTER S WITH CARON 0x8B 0x2039 #SINGLE LEFT-POINTING ANGLE QUOTATION MARK 0x8C 0x0152 #LATIN CAPITAL LIGATURE OE 0x8E 0x017D #LATIN CAPITAL LETTER Z WITH CARON 0x91 0x2018 #LEFT SINGLE QUOTATION MARK 0x92 0x2019 #RIGHT SINGLE QUOTATION MARK 0x93 0x201C #LEFT DOUBLE QUOTATION MARK 0x94 0x201D #RIGHT DOUBLE QUOTATION MARK 0x95 0x2022 #BULLET 0x96 0x2013 #EN DASH 0x97 0x2014 #EM DASH 0x98 0x02DC #SMALL TILDE 0x99 0x2122 #TRADE MARK SIGN 0x9A 0x0161 #LATIN SMALL LETTER S WITH CARON 0x9B 0x203A #SINGLE RIGHT-POINTING ANGLE QUOTATION MARK 0x9C 0x0153 #LATIN SMALL LIGATURE OE 0x9E 0x017E #LATIN SMALL LETTER Z WITH CARON 0x9F 0x0178 #LATIN CAPITAL LETTER Y WITH DIAERESIS
shanjian- I also have other problem on NT (not just 95 and 98). See the attached test page, on my NT4J, "MS Sans Serif" and "MS Serif" have problem on several places. I will attach the screen shot later. It have no problem on b7 (on NT)
Attached image screenshot on my NT4j —
you can see the following characters are wrong on my NT4J 0x82 0x201A #SINGLE LOW-9 QUOTATION MARK 0x83 0x0192 #LATIN SMALL LETTER F WITH HOOK 0x84 0x201E #DOUBLE LOW-9 QUOTATION MARK 0x85 0x2026 #HORIZONTAL ELLIPSIS 0x86 0x2020 #DAGGER 0x87 0x2021 #DOUBLE DAGGER 0x88 0x02C6 #MODIFIER LETTER CIRCUMFLEX ACCENT 0x89 0x2030 #PER MILLE SIGN 0x8A 0x0160 #LATIN CAPITAL LETTER S WITH CARON 0x8B 0x2039 #SINGLE LEFT-POINTING ANGLE QUOTATION MARK 0x8C 0x0152 #LATIN CAPITAL LIGATURE OE 0x8E 0x017D #LATIN CAPITAL LETTER Z WITH CARON 0x93 0x201C #LEFT DOUBLE QUOTATION MARK 0x94 0x201D #RIGHT DOUBLE QUOTATION MARK 0x95 0x2022 #BULLET 0x96 0x2013 #EN DASH 0x97 0x2014 #EM DASH 0x98 0x02DC #SMALL TILDE 0x99 0x2122 #TRADE MARK SIGN 0x9A 0x0161 #LATIN SMALL LETTER S WITH CARON 0x9B 0x203A #SINGLE RIGHT-POINTING ANGLE QUOTATION MARK 0x9C 0x0153 #LATIN SMALL LIGATURE OE 0x9E 0x017E #LATIN SMALL LETTER Z WITH CARON 0x9F 0x0178 #LATIN CAPITAL LETTER Y WITH DIAERESIS MS Sans Serif can display 0x80 0x20AC #EURO SIGN but not "MS Serif" B7, 2018 and 2019 have no problem on both "MS Sans Serif" and "MS Serif"
Problem for 0x80~0x9f is more complicate and platform(localization) specific. Bug 106803 was filed for this. 0xb7 is a different problem by nature and let's take care of it here.
ok, please file seperate bug against other characters. It seems the bug is in different places. r=ftang for http://bugzilla.mozilla.org/attachment.cgi?id=54945&action=view
Comment on attachment 54945 [details] [diff] [review] proposed patch r=ftang ro the b7 problem Please file seperate bug to track other problem with MS Sans Serif
Attachment #54945 - Attachment is obsolete: true
Comment on attachment 54945 [details] [diff] [review] proposed patch sorry. it should be has=review, not obsolete
Attachment #54945 - Attachment is obsolete: false
Attachment #54945 - Flags: review+
Marc, Could you sr my patch? Thx!
Comment on attachment 54945 [details] [diff] [review] proposed patch sr=attinasi
Attachment #54945 - Flags: superreview+
fix was checked in on 10/26.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I couldn't reproduce this problem on 11-19 trunk build - the mid dot is displayed fine. Mark it as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: