Issue 69468

Summary: Keyboard unicode input (Ctrl+Shift+NNN) fails
Product: General Reporter: Joe Smith <jes>
Component: codeAssignee: thorsten.martens
Status: CLOSED NOT_AN_OOO_ISSUE QA Contact: issues@framework <issues>
Severity: Trivial    
Priority: P3 CC: ahz001, issues, khirano, kpalagin, lohmaier
Version: OOo 2.0.4Keywords: oooqa
Target Milestone: ---   
Hardware: All   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description Joe Smith 2006-09-11 21:54:53 UTC
Installed OOo_2.0.4rc1_060904_LinuxIntel_install.tar.gz on Fedora Core 5 with
all updates installed. Unicode input from keyboard no longer works (still works
with 2.0.2 and 2.0.3 on the same system). This affects all (?) keyboard input
(tested: Writer, Calc, Draw/text object, Writer Insert > Note dialog).

To reproduce:
1) File > New > Text document
2) Type Ctrl+Shift+4+1
   The digits are echoed as typed; as soon as either Ctrl or Shift is released,
an 'A' (U+0041) should be inserted[*]
   Instead, as soon as either Ctrl or Shift is released, the echoed digits
disappear and nothing is inserted.

[*]This is the standard behavior for Gtk apps; currently an additional character
(any character) must be typed for OOo to accept the unicode character (See 
Issue 59974).

This is a regression from 2.0.3 and a P2 item, IMO.

I assume someone is trying to fix 59974 (although there is no such comment under
that issue) and maybe has caused some temporary breakage.
Comment 1 aziem 2006-09-17 02:44:42 UTC
On Fedora Core 5 with OOo 2.0.4rc1 (680m3), the "41" disappears as described,
and there is no "A".
Comment 2 Joe Smith 2006-10-03 06:30:15 UTC
Still in 2.0.4rc3.

This will be a big problem for me if 2.0.4 is released with this regression.

It's clearly been seen by at least one other person; can't someone at least
officially confirm/change status on it?
Comment 4 Joe Smith 2006-11-30 19:46:26 UTC
Still present in 2.1.0rc1 -- no change.
Comment 5 Joe Smith 2006-12-07 17:30:11 UTC
Working again in 2.1.0rc2 (Yay!)
Comment 6 Joe Smith 2006-12-07 17:54:20 UTC
> Working again in 2.1.0rc2 (Yay!)

Sorry, no it's still broken in 2.1.0rc2.
I thought I was testing the rc, but it was actually 2.0.2.

My bad. Sorry for the false alarm.
Comment 7 Joe Smith 2007-02-13 19:31:57 UTC
Checked again in OOF680_m7 (build 9118). Still broken.
Comment 8 jjmckenzie 2007-02-14 02:39:12 UTC
Have you confirmed that this problem exists on FC 5?  If so, please update the
status to NEW. I cannot confirm as I do not have FC5 installed on my Thinkpad
and I don't have the time to install it.  Too busy with QA on the Mac Intel. 
Thank you.
James McKenzie
Comment 9 kpalagin 2007-02-14 05:23:36 UTC
Is this feature specific to Fedora? I can't get 4,1 to appear even when typing 
on Suse 10.2 KDE.
(As Fedora has problem installing in Vitrual PC I can't test on Fedora.)
Comment 10 Joe Smith 2007-02-17 04:17:44 UTC
Ok, maybe a little progress: I came across a message on
saying that the Gtk Unicode input method had changed recently. With that hint I
found that the change came with Gtk 2.10:

GTK+ - GTK+-2.10 Release notes

> GTK+ 2.10 Specific Notes
> ========================
> * The hexadecimal Unicode input feature has been reworked. It no longer
>   blocks the use of the sixteen Ctrl-Shift-<hex digit> key sequences. Now
>   it only uses Ctrl-Shift-u.
> ...

Right--who reads release notes ;-)

And some helpful discussion here:

rrwo hates software: Gnome's Character Map

Fedora 5 is still using gtk+ 2.8, so Ctrl+Shift+u doesn't work for any apps on
my system. But it still doesn't explain why OOo >2.0.2 doesn't work with
Comment 11 Joe Smith 2007-06-02 20:25:49 UTC
I recently upgraded my system to Fedora 7, which includes GTK+ 2.10.

Now, OOo--both the Fedora-packaged and the version--works as
specified above: typing Ctrl+Shift+u begins a hex code input sequence and Enter
or Space ends it.

I am still seeing reports of problems with this feature, however it seems likely
that the problem is introduced downstream: either the Linux distro does not
include Gtk 2.10, or the distro has modified the OOo code, or the keyboard
handling is trapping Ctrl+Shift+u for another purpose.

I would suggest resolving/closing this issue as either INVALID or WORKSFORME.
Comment 12 lohmaier 2009-04-01 18:18:04 UTC
as already mentioned, this is a feature of GTK, not OOo and GTK changed the
default (now) long time ago.

Thus finally closing this lost issue as invalid (as it should have been two
years ago:-).
Comment 13 lohmaier 2009-04-01 18:18:28 UTC