Last Comment Bug 4388 - Enable 8-bit input for 8859-1
: Enable 8-bit input for 8859-1
Status: VERIFIED FIXED
:
Product: MailNews Core
Classification: Components
Component: Composition (show other bugs)
: Trunk
: x86 Windows NT
: P3 major (vote)
: M5
Assigned To: tague
: sujay
:
Mentors:
: 5267 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 1999-03-29 16:23 PST by Katsuhiko Momoi
Modified: 2008-07-31 01:22 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Katsuhiko Momoi 1999-03-29 16:23:06 PST
** 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.
Comment 1 nhottanscp 1999-03-29 17:12:59 PST
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).
Comment 2 nhottanscp 1999-04-05 11:27:59 PDT
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.
Comment 3 Greg Kostello 1999-04-06 09:53:59 PDT
This should be fixed after I integrate in the I18N converters. This work most
likely will not get done until M5.
Comment 4 bobj 1999-04-06 10:09:59 PDT
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.
Comment 5 bobj 1999-04-06 10:18:59 PDT
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...
Comment 6 nhottanscp 1999-04-19 11:17:59 PDT
*** Bug 5267 has been marked as a duplicate of this bug. ***
Comment 7 lchiang 1999-04-19 12:58:59 PDT
Does this happen outside of the mail compose window?  If so, then I'll need to
assign the QA contact to beppe's group.
Comment 8 nhottanscp 1999-04-19 13:05:59 PDT
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.
Comment 9 Katsuhiko Momoi 1999-04-19 14:18:59 PDT
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.
Comment 10 Greg Kostello 1999-04-25 23:22:59 PDT
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.
Comment 11 lchiang 1999-04-28 10:51:59 PDT
Per momoi's comments on 04/19/99 14:18, this is a general Editor bug.  Sujay -
your area?
Comment 12 Greg Kostello 1999-04-28 12:05:59 PDT
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.
Comment 13 tague 1999-04-28 13:47:59 PDT
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 #
Comment 14 tague 1999-04-29 11:39:59 PDT
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.
Comment 15 Katsuhiko Momoi 1999-05-03 19:38:59 PDT
** 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?
Comment 16 tague 1999-05-04 17:12:59 PDT
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.
Comment 17 sujay 1999-05-05 09:28:59 PDT
momoi, you'll need to help me verify this one and mark it VERIFIED-FIXEd..
thanks...
Comment 18 Katsuhiko Momoi 1999-05-05 19:29:59 PDT
**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.
Comment 19 bobj 1999-05-11 15:23:59 PDT
Changed TFV to M5, since that's the M-build in which it actually got fixed.

Note You need to log in before you can comment on or make changes to this bug.