Closed
Bug 4165
Opened 26 years ago
Closed 25 years ago
nsComposeAppCore should not use ToNewCString for unicode conversion
Categories
(MailNews Core :: Internationalization, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
M5
People
(Reporter: nhottanscp, Assigned: nhottanscp)
Details
ToNewCString only works for Latin1. Compose need to convert unicode to a mail charset (can be taken from a pref and the charset menu). I will mail a sample code to Jean-Francois.
Assignee | ||
Updated•26 years ago
|
Component: Composition → Internationalization
QA Contact: 4080 → 1308
Target Milestone: M4
Actually, ToNewCString only works for ASCII (not Latin1) since it probably is just casting off the high byte of the UCS character.
Assignee | ||
Updated•25 years ago
|
Assignee: ducarroz → nhotta
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•25 years ago
|
||
I checked in the code to do the conversion. We still have two problems before we can do the verification. #4388 - Enable 8-bit input for 8859-1 #4394 - libmime to export QP/Base64 encoders
Assignee | ||
Comment 4•25 years ago
|
||
#4394 has been resolved. I verified it (for QP only) by putting 8 bit characters hard coded. #4388- By using 4/2 build, I cannot input 8 bit chars but paste from other app is working. As my build is crashing in Ender when I try to send, I cannot try pasted 8 bit string with the new QP code. I will try again on Monday.
Assignee | ||
Comment 5•25 years ago
|
||
It doesn't work on 4/5 build. I pulled the today's build. In the message composer, a returned text from Ender does not contain 8 bit characters. They are visible in the view but they are seemed to be stripped out.
Comment 6•25 years ago
|
||
nhotta: Please clearify which file use ToNewCString, and in what action will cause such code get code.
Assignee | ||
Comment 7•25 years ago
|
||
It was in nsComposeAppCore.cpp, the fix was checked in. The bug is still open because there is a blocking bug (#4388) prevents the verification.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M4 → M5
Assignee | ||
Comment 8•25 years ago
|
||
Changing to M5 since #4388 is M5.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•25 years ago
|
||
Change status to 'FIXED' verification is blocked by #4388. To verify this, try non us-ascii characters in the body then check the message in 4.5.
Comment 10•25 years ago
|
||
This fix can be verified now for Latin 1 as the 2 blocking bugs have been resolved. For Japanese, it's still not possible to see the results of send. I can go ahead and verify this based on Latin 1 send which is now working for the header and body, or can wait until the Japanese send becomes possible.
Assignee | ||
Comment 11•25 years ago
|
||
You can verify this by sending Latin1 body.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 12•25 years ago
|
||
** Checked with 4/29/99 Win32 build ** It is possible to send Latin 1 mail body containing 8-bit characters in it. They are properly QP-encoded in Latin 1. This confirms that the fix is working OK. Marking the fix verified.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•