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.
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
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.
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.
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
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
change the TM to M6
Frank will probably be out on paternity leave during M8. Moved to M9.
erik, could you take care this also ? Thanks.
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.
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.
I verified this in 2000020108 Win 32 build under Win 95J and Winnt 4.0J.