Bug 7642 - Entering SS through Lock+ssharp (german) using new type
Summary: Entering SS through Lock+ssharp (german) using new type
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: lowest enhancement
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: l10n, patch
Depends on:
Blocks:
 
Reported: 2006-07-26 08:29 UTC by Fabian Hombsch
Modified: 2010-12-03 13:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Hombsch 2006-07-26 08:29:14 UTC
I would like to be able to type a doubled S on a german keyboard with Lock+ssharp.

In german, the letter ß (ssharp) (formerly composed out of s and z) exists in
lowercase only unless small caps are used or everything is written in captial
letters. In this case it would be replaced by doubled S.

current behaviour: FOUR_LEVEL;
key <AE11> { [ ssharp, question, backslash, questiondown ] };

desired behaviour:
if Caps Lock is active and neither shift nor AltGr (<RALT>) is pressed, two
uppercase S should be printed.

possible solution:
I would introduce a new type for this letter like this:
partial default xkb_types "default" {
    type "SS" {
        modifiers = Shift+Lock+LevelThree;
	map[None] = Level1;
	map[Shift] = Level2;
	map[LevelThree] = Level3;
	map[Shift+LevelThree] = Level4;
        map[Lock]  = Level5;
	map[Lock+Shift] = Level2;
	map[Lock+LevelThree] = Level3;
	map[Lock+Shift+LevelThree] = Level4;
	level_name[Level1] = "Base";
	level_name[Level2] = "Shift";
	level_name[Level3] = "Alt Base";  
	level_name[Level4] = "Shift Alt";  
        level_name[Level5] = "Lock";
    };
};
Does someone know how to print two symbols with one keypress?

kind regards, Fabian
Comment 1 Sergey V. Udaltsov 2006-07-29 12:56:02 UTC
AFAIK two characters per one keypress is beyond the scope of things XKB can do.
May be, you could do it using the Input Methods?
Comment 2 Fabian Hombsch 2007-04-01 05:13:30 UTC
in /usr/share/X11/locale/en_US.UTF-8 at the end, it seems possible to print two symbols with one keystroke:

> # Khmer digraphs
> # A keystroke has to generate several characters, so they are defined
> # in this file
> 
> <U17fb>    :   "ុះ"
> <U17fc>    :   "ុំ"
> <U17fd>    :   "េះ"
> <U17fe>    :   "ោះ"
Comment 3 Fabian Hombsch 2007-04-01 05:18:46 UTC
drawbacks of the proposed type for german key ß?\¿:
Shift_cancels_caps has to be superseded by "be able to type questionmark",
so a lowercase ssharp "ß" would be impossible to type with caps lock turned on.
Comment 4 Fabian Hombsch 2007-10-02 10:27:29 UTC
I managed to type SS using Lock+ssharp on my modified german keyboard.
I want to request a change to the german keyboard to make this the standard behaviour.
The only problem left is that I need a Unicode code point position that will never be overwritten by new additions to the Unicode standard.
Does someone know how to find out about them?
Greetings, Fabian.

P.S. In order to produce SS, I am using the same method as for the Khmer digraphs in Bug 5389.
Comment 5 Sergey V. Udaltsov 2007-10-02 12:05:12 UTC
> The only problem left is that I need a Unicode code point position that will
> never be overwritten by new additions to the Unicode standard.
Why just cannot you use existing SS in unicode?

> Does someone know how to find out about them?
I actually never heard about "reserved to be never used" areas in Unicode.
Comment 6 Fabian Hombsch 2007-10-03 09:19:28 UTC
> Why not existing SS in unicode?
I cannot find it in Unicode. By the way, it is not a character of its own. There is nothing special about it. It`s just two uppercase S which happen to be used as a capital version of 'ß'.

> I actually never heard about "reserved to be never used" areas in Unicode.
Then I will just have to pick some reserved codepoint.

Greetings, Fabian.

Comment 7 Fabian Hombsch 2007-10-03 12:12:38 UTC
Hello folks,
this is my proposal for the german keyboard modification (to allow for ssharp to be capitalized as SS).
It is a mix of commands and the output of the diff command. I hope it can be easily converted to a patch like this. Here it is:

prompt$ cd /usr/share/X11/xkb/symbols
prompt$ diff -U 0 de_old de

--- de_old      2006-10-20 22:26:15.000000000 +0200
+++ de  2007-10-03 18:31:13.000000000 +0200
@@ -17 +17 @@
-    key <AE11> { [    ssharp,   question,    backslash, questiondown ] };
+    key <AE11> {type[Group1]="SS",  symbols[Group1]= [    ssharp,   question,    backslash, questiondown, 0x1001E9C ]};

prompt$ cd ../../locale/iso8859-15
prompt$ diff -U 0 Compose_old Compose

--- Compose_old   2007-10-01 18:19:22.000000000 +0200
+++ Compose    2007-10-02 18:56:52.000000000 +0200
@@ -448,0 +449,2 @@
+# Extension by Fabian Hombsch:
+<U1E9C>                                 : "SS"  # Twice a capital S

prompt$ cd ../../xkb/types
prompt$ diff -U 0 extra_old extra

--- extra_old   2006-10-20 22:26:16.000000000 +0200
+++ extra       2007-10-03 20:49:24.000000000 +0200
@@ -108,0 +109,33 @@
+
+// type for german ssharp which is capitalized SS.
+// CHARACTERISTICS:
+// It is FOUR_LEVEL with the exception that the fifth level
+// is mapped to the Lock modifier.
+// If other modifiers are used, the Lock state is ignored.
+// DETAILS ABOUT GERMAN:
+// The capital form of ssharp (called sharp s) only exists for
+// completely capitalized Text, not at the beginning of sentences
+// or nouns (nouns have a captial letter at the beginning in german).
+// The ssharp key, to the right of the zero key, takes this into
+// account and has a questionmark mapped on shift-ssharp since
+// normally no capital version is needed.
+// When typing with active capsLock, this key type is needed to
+// output two capital letters S because this is the only german key
+// whose capital letter is not the same as the one typed with shift.
+
+    type "SS" {
+        modifiers = Shift+Lock+LevelThree;
+       map[None] = Level1;
+       map[Shift] = Level2;
+       map[LevelThree] = Level3;
+       map[Shift+LevelThree] = Level4;
+        map[Lock]  = Level5;
+       map[Lock+Shift] = Level2;
+       map[Lock+LevelThree] = Level3;
+       map[Lock+Shift+LevelThree] = Level4;
+       level_name[Level1] = "Base";
+       level_name[Level2] = "Shift";
+       level_name[Level3] = "Alt Base";
+       level_name[Level4] = "Shift Alt";
+        level_name[Level5] = "Lock";
+    };
Comment 9 Fabian Hombsch 2007-10-07 04:14:52 UTC
Thanks, Sergey, U+1e9e is the right spot.
The unicode character seems to be almost accepted in unicode.

As I read in the sources you provided, 
it is intended for use in very special cases, though.
It should be used when capitalized text is needed but the loss of information is inacceptable. 
For normal texts though, the standard rule "ß" (sharp s) -> "SS" should be applied.

I come to the conclusion that this special unicode character should be picked and replaced by "SS" using compose files.
In case the compose file lacks or fails but the fonts support the character, the result is still acceptable.
With available fonts, the user can also choose to delete the line in his compose file in order to write this special character.
Comment 10 Fabian Hombsch 2007-10-07 04:15:07 UTC
Thanks, Sergey, U+1e9e is the right spot.
The unicode character seems to be almost accepted in unicode.

As I read in the sources you provided, 
it is intended for use in very special cases, though.
It should be used when capitalized text is needed but the loss of information is inacceptable. 
For normal texts though, the standard rule "ß" (sharp s) -> "SS" should be applied.

I come to the conclusion that this special unicode character should be picked and replaced by "SS" using compose files.
In case the compose file lacks or fails but the fonts support the character, the result is still acceptable.
With available fonts, the user can also choose to delete the line in his compose file in order to write this special character.
Comment 11 Sergey V. Udaltsov 2007-10-07 05:47:58 UTC
Fabian, I see your point. My question was - why not use 1e9e instead of 1e9c?
Also I do not like the name "SS" for the key type. Could you please it name it in more generic way - so may be someone could use it in a future?
Comment 12 Fabian Hombsch 2007-10-07 10:22:57 UTC
Sergey, 
there was no reason for picking 1e9c. It was just randomly picked.
Sorry for my double comment.
I am posting a corrected proposal, now.
I altered some comments, the Unicode code point and the name of the key type.
Feel free to alter the latter since I don`t really care about it.
Here it goes:

--- /usr/share/X11/locale/iso8859-15/Compose_old 2007-10-07 16:32:44.000000000 +0200
+++ /usr/share/X11/locale/iso8859-15/Compose     2007-10-07 16:37:12.000000000 +0200
@@ -447,0 +448,2 @@
+# Normal (not dead) keys that need to output more than one character
+<U1E9E>                                 : "SS" # Twice a capital S, used for capitalization of ssharp

--- /usr/share/X11/xkb/symbols/de_old      2007-09-16 18:53:37.000000000 +0200
+++ /usr/share/X11/xkb/symbols/de  2007-10-07 16:48:55.000000000 +0200
@@ -17 +17,9 @@
-    key <AE11> { [    ssharp,   question,    backslash, questiondown ] };
+    key <AE11> {type[Group1]="FOUR_LEVEL_PLUS_LOCK",  symbols[Group1]=
+                  [ssharp, question, backslash, questiondown, 0x1001E9E ]};
+// The unicode capital letter sharp s U+1E9E is transformed to "SS"
+// to match the rules for capitalizing sharp s in german.
+// If the capital sharp s is needed, delete the line
+// starting with <U1E9C> from /usr/share/X11/locale/iso8859-15/Compose.
+// If both doubled S and capital sharp s are needed, use  0x1001E9E
+// for capital sharp s and some free unicode codepoint like 0x1001E9C
+// for doubled S. Don`t forget to change this in the Compose file, too.

--- /usr/share/X11/xkb/types/extra_old   2007-09-16 18:53:38.000000000 +0200
+++ /usr/share/X11/xkb/types/extra       2007-10-07 16:25:51.000000000 +0200
@@ -110,0 +111,33 @@
+// type for e.g. german ssharp which is capitalized SS.
+// CHARACTERISTICS:
+// It is FOUR_LEVEL with the exception that the fifth level
+// is mapped to the Lock modifier.
+// If other modifiers are used, the Lock state is ignored.
+// DETAILS ABOUT GERMAN:
+// The capital form of ssharp (called sharp s) only exists for
+// completely capitalized Text, not at the beginning of sentences
+// or nouns (nouns have a captial letter at the beginning in german).
+// The ssharp key, to the right of the zero key, takes this into
+// account and has a questionmark mapped on shift-ssharp since
+// normally no capital version is needed.
+// When typing with active capsLock, this key type is needed to
+// output two capital letters S because this is the only german key
+// whose capital letter is not the same as the one typed with shift.
+
+    type "FOUR_LEVEL_PLUS_LOCK" {
+        modifiers = Shift+Lock+LevelThree;
+       map[None] = Level1;
+       map[Shift] = Level2;
+       map[LevelThree] = Level3;
+       map[Shift+LevelThree] = Level4;
+        map[Lock]  = Level5;
+       map[Lock+Shift] = Level2;
+       map[Lock+LevelThree] = Level3;
+       map[Lock+Shift+LevelThree] = Level4;
+       level_name[Level1] = "Base";
+       level_name[Level2] = "Shift";
+       level_name[Level3] = "Alt Base";
+       level_name[Level4] = "Shift Alt";
+        level_name[Level5] = "Lock";
+    };
+
Comment 13 Sergey V. Udaltsov 2007-10-07 14:21:38 UTC
That's better. I'll commit it. Except for the Compose part which should be committed as libx11 data.
Comment 14 Matt Turner 2010-12-03 13:39:48 UTC
I don't know if part of this patch has been committed or what from looking at the comments. It is quite old and inactive though. Closing.

If another patch is required, please send it to xorg-devel@lists.x.org for review/inclusion.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.