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

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P1)

Description

[Teruko Kobayashi]

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.

Comment 1

[Frank Tang]

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

Comment 2

[Frank Tang]

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.

Comment 3

[Frank Tang]

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.

Comment 4

[Frank Tang]

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.

Comment 5

[Frank Tang]

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

Comment 6

[Frank Tang]

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

Comment 7

[Frank Tang]

change the TM to M6

Comment 8

[bobj]

Frank will probably be out on paternity leave during M8.  Moved to M9.

Comment 9

[Frank Tang]

erik, could you take care this also ? Thanks.

Comment 10

[Erik van der Poel]

I recently made a change related to this. Could you try it again, Teruko?

Comment 11

[Teruko Kobayashi]

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.

Comment 12

[leger]

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!

Comment 13

[Erik van der Poel]

Teruko, could you test this again please?

Comment 14

[Erik van der Poel]

This was fixed a while ago.

Comment 15

[Teruko Kobayashi]

I verified this in 2000020108 Win 32 build under Win 95J and Winnt 4.0J.