Closed Bug 4388 Opened 25 years ago Closed 25 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: 25 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.