Closed
Bug 71542
Opened 24 years ago
Closed 23 years ago
Japanese characters for Web page title display as trash in printer window's document name column
Categories
(Core :: Internationalization, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: wesleyg, Assigned: rods)
Details
(Keywords: intl)
Attachments
(2 files)
122.25 KB,
image/jpeg
|
Details | |
1.67 KB,
patch
|
Details | Diff | Splinter Review |
<summary> Japanese characters for Web page title display as trash in printer window's document name column <repro environment> build 03-09-04 + Win2000-JA not repro on: IE5.5+ Win2000-JA <repro step> 1. go to start|settings|printers, open the window for your default printer 2. open browser to http://www.toei.co.jp , or another Japanese web page with a title using Japanese characters 3. print the page, view the document name in the printer status window <result> Japanese characters for Web page title display as trash in printer window's document name column
Comment 1•24 years ago
|
||
Reassign to dcone, similar to bug 69610?
Assignee: nhotta → dcone
Keywords: intl
Updated•24 years ago
|
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
The way the characters are trashed and where they appear would suggest this is not the same as #69610.
Comment 5•23 years ago
|
||
per triage: reassigning to rods
Assignee: dcone → rods
Target Milestone: --- → mozilla0.9.1
Assignee | ||
Comment 6•23 years ago
|
||
Assignee | ||
Comment 7•23 years ago
|
||
Erik, could you review this patch? I am not really sure about the UNICODE or MBCS parts of the patch. I think the UNICODE is fine but the MBCS is probably wrong. Casting to (wchar_t*) is probably bad.
Status: NEW → ASSIGNED
Comment 8•23 years ago
|
||
Instead of using the _UNICODE ifdef, we normally call the 'W' functions directly. In this case, that would be ::StartDocW(). You can pass Unicode strings to this function directly. QA can then test this on several platforms (English/Japanese Windows 95/98/NT/2000) to see if StartDocW really works everywhere.
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla1.0
Comment 9•23 years ago
|
||
Nominating for nsbeta1 and M0.9.1. Looks like we have a proposed patch.
Keywords: nsbeta1
Comment 10•23 years ago
|
||
Rods - If we have a proposed patch, why are we waiting until 1.0 to fix this?
Comment 11•23 years ago
|
||
Rods/Vishy - Can someone pls explain the milestone of M1.0, if a patch already exist?
Comment 12•23 years ago
|
||
No idea, rod?
Assignee | ||
Comment 13•23 years ago
|
||
I am really not the right guy to have this bug. I AM the right guy to help out with this bug. It should really be someone else bug. Now that Erik is gone, who can help out with this? I need someone to test the proposed patch.
Comment 14•23 years ago
|
||
Adding ftang to cc: list. Ftang - Can you help out on this one. Seems like rods needs help, and this may be out of his area of expertise.
Updated•23 years ago
|
Comment 15•23 years ago
|
||
Per Vishy's request, setting priority P2 and milestone to M0.9.2, so that we can triage.
Severity: normal → major
Priority: -- → P2
Comment 16•23 years ago
|
||
I believe this was fixed by Rod checkin to fix localization issues with the print dialog a few weeks ago. Marking Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 17•23 years ago
|
||
Fixed verified on 08-22 trunk build on Win2k-CN.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•