Closed Bug 4388 Opened 26 years ago Closed 26 years ago

Enable 8-bit input for 8859-1

Categories

(MailNews Core :: Composition, defect, P3)

x86
Windows NT

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: momoi, Assigned: tague)

References

Details

** Observed with 3/19/99 5.0 build ** Currently, it is not possible input 8-bit accented characters for European languages into the text body window using the ALTGr + Number Key methos on US-Windows. In the Subject window, 8-bit input is working OK. It is also very difficult to copy/paste from other windows into the text body window. (once in a while it seems to work but in the main copy/paste does not work.
Assignee: nhotta → kostello
Target Milestone: M4
Reasigning to Ender. We need this for M4 (PC) in order to send Latin1 mails (plain text). In case of plain text, we need Latin1 in UCS2. For html (if M4 supports html mails), accented chars to be converted to named entity. BTW, message compose uses utf-8 internally because i18n no longer support per charset string manipulation utilities (e.g. NextChar for multi-byte). So, it needs nsString from Ender (in fact nsString is used already).
QA Contact: 4080 → 4495
Status: NEW → ASSIGNED
4/5 build, paste 8 bit chars from other app is working. I can see É in the mail compose window. But they are stripped out when the message comose receives the text (I checked that in the debugger) so the sent out mail only contains ascii chars. I would like this (8 bit char stripping out problem) to be fixed for M4.
Target Milestone: M4 → M5
This should be fixed after I integrate in the I18N converters. This work most likely will not get done until M5.
Target Milestone: M5 → M4
I can create the copy/paste problem by just using the editor task (4/5 build). I copied ABCאבדהוזDEF from Windows Character Map accessory and pasted into the editor - works and displays correctly. Then I copy the same string that I just pasted and try to paste it somewhere else within the editor and it just pastes "ABCDEF" (all non-ASCII is missing). I try to paste into another app (e.g., Notepad)and it also loses the non-ASCII characters. Looks like a bug in the copy operation.
Target Milestone: M4 → M5
Whoops, unintentionally reset to M4 because bugzilla was stuck in a modal dialog and I didn't notice for a day that my comments from yesterday had not been committed...
*** Bug 5267 has been marked as a duplicate of this bug. ***
QA Contact: 4495 → 4080
Does this happen outside of the mail compose window? If so, then I'll need to assign the QA contact to beppe's group.
I am not sure about inside/outside definition but the characters can be seen inside the mail compose window. Actual data is missing when the message compose receives text from Ender.
This is probably a general Editor bug. If you bring up the Editor window and try to input 8-bit accented characters directly, it does not work. Using AltGr+NumPad nor a different keyboard such the French keyboard does not work. You can copy/paste 8-bit accented characters into the Editor window but we are not sure if that can be saved -- there is no "save" yet in the Editor window. In the mail compose window, actual 8-bit data is not sent.
At least a partial fix. Now the content model is being output through the I18N encoding filters. The document character set is written out as part of the XIF encoding. Later, a converter is looked for with that name. For now, if the document contains no charset information, ISO-8859-1 is used.
QA Contact: 4080 → 4079
Per momoi's comments on 04/19/99 14:18, this is a general Editor bug. Sujay - your area?
Assignee: kostello → tague
Status: ASSIGNED → NEW
Tague and I discussed this and I'm reassigning this to him. The problem is that the events coming into the system are converted to ASCII not Unicode. This happens somewhere up in the widget code. The editor simply adds whatever key values its told to input.
Status: NEW → ASSIGNED
This functionality should just fall out of the work that I am doing for input methods and international keyboards. As Greg said above, there isn't much that the editor can do about this, they aren't getting the app. and #
Target Milestone: M5 → M6
hrmph...i should write legible bug comments. this isn't going to get fixed for M5, since there are too many different groups involved in making this fix happen. reassigning to M6.
** Checked with 5/3/99 Win32 M6 candidate build ** Using ALTGr+Num Pad keys, I'm now able to input Latin 1 accented characters and they go out intact also. Did someone put in a workaround for this?
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
rods changes to nsWindow.cpp for the IME support should have taken care of this. i verified that you can type with various international keyboards (like German) and get accent characters and the proper layouts.
momoi, you'll need to help me verify this one and mark it VERIFIED-FIXEd.. thanks...
Status: RESOLVED → VERIFIED
**Checked with 5/5/99 Win32 M5 build ** I'm going to mark this fixe verified for the following limited cases: A. Under the Windows keyboard EN B. Use ALTGr (right ALT) + Num Keypad to input various accented characters from Windows-1252 charset table. These things work. I found, however, use of different keyboards, e.g. FR, CS, etc., does not work all that well in that mapping is wrong often. RU, for example, doesn't even pick up a Cyrillic font at all. I'll now mark this fix verified in the above limited sense and then open a new set of bugs for keyboard uses.
Target Milestone: M6 → M5
Changed TFV to M5, since that's the M-build in which it actually got fixed.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.