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)
Tracking
()
VERIFIED
FIXED
M14
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.
Reporter | ||
Updated•26 years ago
|
Priority: P3 → P1
Summary: Viewer.exe does not display Japanese page → Viewer.exe does not display Japanese page
Target Milestone: M3
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 1•26 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
Summary: Viewer.exe does not display Japanese page → apprunner.exe does not display Japanese page
Comment 2•26 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•26 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•26 years ago
|
Whiteboard: find the problem. Working on a fix.
Comment 4•26 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•26 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•26 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•26 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•26 years ago
|
Target Milestone: M4 → M5
Comment 6•26 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•26 years ago
|
Target Milestone: M5 → M6
Comment 7•26 years ago
|
||
change the TM to M6
Updated•26 years ago
|
Target Milestone: M6 → M8
Updated•26 years ago
|
Assignee: ftang → erik
Status: ASSIGNED → NEW
Comment 9•26 years ago
|
||
erik, could you take care this also ? Thanks.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 10•26 years ago
|
||
I recently made a change related to this. Could you try it again, Teruko?
Reporter | ||
Comment 11•26 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•26 years ago
|
Target Milestone: M9 → M12
Assignee | ||
Updated•26 years ago
|
Target Milestone: M12 → M14
Comment 12•25 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•25 years ago
|
||
Teruko, could you test this again please?
Assignee | ||
Comment 14•25 years ago
|
||
This was fixed a while ago.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 15•25 years ago
|
||
I verified this in 2000020108 Win 32 build under Win 95J and Winnt 4.0J.
Status: RESOLVED → VERIFIED
Updated•25 years ago
|
Whiteboard: [PDT+]
You need to log in
before you can comment on or make changes to this bug.
Description
•