If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in M14

Status

()

Core
Internationalization
P1
critical
VERIFIED FIXED
19 years ago
13 years ago

People

(Reporter: Teruko Kobayashi, Assigned: Erik van der Poel)

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Priority: P3 → P1
Summary: Viewer.exe does not display Japanese page → Viewer.exe does not display Japanese page
Target Milestone: M3

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 1

19 years ago
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

Updated

19 years ago
Summary: Viewer.exe does not display Japanese page → apprunner.exe does not display Japanese page

Comment 2

19 years ago
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

19 years ago
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.

Updated

19 years ago
Whiteboard: find the problem. Working on a fix.

Comment 4

19 years ago
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.

Updated

19 years ago
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

Comment 5

19 years ago
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

Updated

19 years ago
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

Updated

19 years ago
Target Milestone: M4 → M5

Comment 6

19 years ago
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

Updated

19 years ago
Target Milestone: M5 → M6

Comment 7

19 years ago
change the TM to M6

Updated

19 years ago
Target Milestone: M6 → M8

Updated

19 years ago
Target Milestone: M8 → M9

Comment 8

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

Updated

19 years ago
Assignee: ftang → erik
Status: ASSIGNED → NEW

Comment 9

19 years ago
erik, could you take care this also ? Thanks.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 10

19 years ago
I recently made a change related to this. Could you try it again, Teruko?
(Reporter)

Comment 11

19 years ago
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.
(Assignee)

Updated

18 years ago
Target Milestone: M9 → M12
(Assignee)

Updated

18 years ago
Target Milestone: M12 → M14
(Assignee)

Updated

18 years ago
Keywords: beta1

Comment 12

18 years ago
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!
(Assignee)

Comment 13

18 years ago
Teruko, could you test this again please?
(Assignee)

Comment 14

18 years ago
This was fixed a while ago.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 15

18 years ago
I verified this in 2000020108 Win 32 build under Win 95J and Winnt 4.0J.
Status: RESOLVED → VERIFIED

Updated

18 years ago
Whiteboard: [PDT+]
You need to log in before you can comment on or make changes to this bug.