Closed Bug 3819 Opened 26 years ago Closed 25 years ago

Window GFX Unicode Text Drawing- Non ASCII font face in prefs.js does not convert correctly

Categories

(Core :: Internationalization, defect, P1)

x86
Windows 95
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: teruko, Assigned: erik)

Details

(Whiteboard: [PDT+])

Tested 3-15-99 and 3-16-99 Win32 under Windows 95J and Winnt 4.0J. After I copied the pref.js file which I got from Frank to the same directory the Viewer.exe, the Japanese page such as http://home.jp.netscape.com does not display Japanese correctly.
Priority: P3 → P1
Summary: Viewer.exe does not display Japanese page → Viewer.exe does not display Japanese page
Target Milestone: M3
Status: NEW → ASSIGNED
It is work in soem system but not others. Teruko's 95J (w/o IE 40 does not work Teruko's N%4J does not work Momoi's NT US (w/ IE 5.0 work momoi's NT4J (w/ IE4.0 does not work Lab NT4J (w/o IE4 work Lab 95J does not work I try both debug build and opt build . It seems there are no differences between debug and opt build. It somehow more depend on the machine we are using. IE4.0 maybe a factor
Summary: Viewer.exe does not display Japanese page → apprunner.exe does not display Japanese page
More info. Teruko find out all the NT4J which does work is w/ service package 1 and the one does not work are w/ service pack 3.
More info. we find marian's WinNT4J w/ service pack 3 *work*.... I try to change the code to use CreateFontIndrectW w / LOGFONTW, it does not work. There are some MS document mention UNICODE_CHARSET, but we cannot find it from VC5 include files, nor VC6 include files. Some file on the net show the value is 1 which is the same as what we use- DEFAULT_CHARSET (=1) Both the Debug build and opt build behave the same. We should try using TextOutW instead of ExtTextOutW and see what happen there. Naoki mention the definitation of DEFAULT_CHARSET somehow change between Service Pack 1 and 3 but we do not know what it is now. Naoki fix a 4.5 bug by using TextOutA instead, but that change does not help here.
Whiteboard: find the problem. Working on a fix.
The problem is not complex as we thought. The bug exist on all version of window but somehow some version of window J fallback to a font which we can use and the other fallback to some font we cannot use. The real problem is in layout/base/src/nsPresContext.cpp, when we get the default font face name from nsIPref, we simply treat it as ASCII and set it to the nsString. A wrong conversion apply when the data is in non-ASCII. The real soultion is to decide what charset we should use as in Pref (UTF-8???). For DogFood, the temp solution is to put #ifdef _WIN32 code and use MultiByteToWideChar to convert the data from CP_ACP into unicode and assign to nsString. I am working on the fix.
Summary: apprunner.exe does not display Japanese page → Non ASCII font face in prefs.js does not convert correctly
Whiteboard: find the problem. Working on a fix.
Target Milestone: M3 → M4
Change the Summary from "apprunner.exe does not display Japanese page" to "Non ASCII font face in prefs.js does not convert correctly" The reason we cannot see Japanese is because Non ASCII font face in prefs.js does not convert correctly (in layout/base/src/nsPresContext.cpp) We decide to set the target to M4 since IQA could install ASCII only font face on their machine to test it. The reason it is working on some machines is just luck. Some Japanese machine fallback the font (in CreateFontIndirect) to some font that have Japanese glyph and some other system don't
Summary: Non ASCII font face in prefs.js does not convert correctly → Window GFX Unicode Text Drawing- Non ASCII font face in prefs.js does not convert correctly
Target Milestone: M4 → M5
We still need to solve the non ASCII font face name problem . However, this become less important after erik check in his multi-font unicode rendering solution for window. Change to M6
Target Milestone: M5 → M6
change the TM to M6
Target Milestone: M6 → M8
Target Milestone: M8 → M9
Frank will probably be out on paternity leave during M8. Moved to M9.
Assignee: ftang → erik
Status: ASSIGNED → NEW
erik, could you take care this also ? Thanks.
Status: NEW → ASSIGNED
I recently made a change related to this. Could you try it again, Teruko?
I created simple test case in http://babel/tests/browser/html/font_face_sjis.html. I changed font face to "MS goshic" and "MS mincho" in Japanese, but displaying the characters are same. Tested 6-28-08 Win32 under NT and 95J.
Target Milestone: M9 → M12
Target Milestone: M12 → M14
Keywords: beta1
We need latest info on this to make the call. We believe a lot of work was one on this already. Cannot make PDT+ vs. PDT- without current info. Thanks!
Teruko, could you test this again please?
This was fixed a while ago.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I verified this in 2000020108 Win 32 build under Win 95J and Winnt 4.0J.
Status: RESOLVED → VERIFIED
Whiteboard: [PDT+]
You need to log in before you can comment on or make changes to this bug.