Closed
Bug 4165
Opened 26 years ago
Closed 26 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•26 years ago
|
Assignee: ducarroz → nhotta
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•26 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•26 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•26 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•26 years ago
|
||
nhotta: Please clearify which file use ToNewCString, and in what action will
cause such code get code.
Assignee | ||
Comment 7•26 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•26 years ago
|
Target Milestone: M4 → M5
Assignee | ||
Comment 8•26 years ago
|
||
Changing to M5 since #4388 is M5.
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•26 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•26 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•26 years ago
|
||
You can verify this by sending Latin1 body.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 12•26 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
•