Would you be able to provide a patch?

Also, what was the purpose for the government to create new layout? Why was it done when there is de facto standard layout (as far as I know)? Just a curiosity. Sure I will accept this de-jure standard.

Sorry could not read wikipedia, I do not read German.

Created attachment 75008 [details] [review]
Draft of German T3 layout, without proper level selection keys.

The basic technical requirements for T2 (required levels and associated
modifier keys) are the same as for T3, so it does not make much sense to
provide the more limited T2.

From the freely available information, I am not fully sure how
level/group selection works.  From the proposal:

    http://www.pentzlin.com/ErweiterungDeutscheTastatur2.pdf

it appears that the right Alt key (AltGr) becomes a Level 3 latch, and
Shift+AltGr latches to the "common secondary group".  However,
changing AltGr to a latching key is quite fundamental change, and I do
not see how it would fit with the goal of the DIN 2137 revision of
keeping backward compatibility.  It is hard to imagine that this
change made it into the final standard.

Also, if level/group selection works as the proposal indicate, we will
run into a bug in the server that leaves the keyboard in an unusable
state.

For these two reasons, for now, the patch provides AltGr as Level3 shift
and the right control key as Level5 shift.  This is at least sufficient
to test the rest.

Apart from the xkeyboard-config part, the compose sequences in libX11
might need extension.  I do not have enough understanding of Unicode to
do this.  I is also not specific to the German layout, as the "common
secondary group" is international.  I also do not know whether some of
the composing characters currently used in the "common secondary group"
should be replaced by yet-to-be introduced dead keys.

Your patch is good enough, for the start. Do I understand it right that T3 is still work in progress, by German government?

It is committed now. If there are changes in T3 standard - feel free to reopen this bug.

Since xkeyboard-config is not the area of compose keys, perhaps another bug should be open about compose stuff...

> Do I understand it right that T3 is still work in progress, by German government?

T3 is final, but the official document is not freely available. The characters in the layout can be seen elsewhere, but the details about the exact level selection scheme still needs confirmation.

> Since xkeyboard-config is not the area of compose keys, perhaps another bug should be open about compose stuff...

In principle, you are right, but opening a bug for libX11 in my experience is not a good strategy to "recruit" people.

Denis, can you help to complete the compose sequences to fully support the "commmon secondary group" of ISO/IEC 9995-3:2010?  From what I have seen, you seem to have quite good knowledge for this task.

> (In reply to comment #5)
> Denis, can you help to complete the compose sequences to fully support the
> "commmon secondary group" of ISO/IEC 9995-3:2010?  From what I have seen,
> you seem to have quite good knowledge for this task.

Thank you for the layout.

I guess some things like dead_stroke (to get single characters like ħ) or dead_belowdot followed by dead_acute (to get character sequences like ẹ́) don't work yet because we need to complete the compose sequences.
Where is that done?

http://www.open-std.org/Jtc1/sc35/WG1/docs/info1-9995-3.pdf defines (some of?) those sequences.

Would these compose sequences go in xorg/lib/libX11/tree/nls/en_US.UTF-8/Compose.pre or another file?

A git patch for git://git.freedesktop.org/git/xorg/lib/libX11.git is prefered.
Cf git-format-patch(1).

Please be sure to build the patched version and run nls/compose-check.pl.  I usually do:

:; git clone -l libX11 libX11-compile
:; cd libX11-compile
:; ./autogen.sh ; make -j4 ; make check

An out of tree build also works well.

Then run git format-patch to generate the patch to submit.

If it is a single commit, then:

:; git format-patch HEAD^

will do the trick.

It would be best to open a bug at:

https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

component «Lib/Xlib (data)» version «git».

Reference this bug in the new one.

It is possible that some of the sequences might conflict with existing sequences.  If so, the existing ones win.  The «make check» step should point out any such problems.  Look for the compose-check.pl section in the output.

> It would be best to open a bug at:

> https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

> component «Lib/Xlib (data)» version «git».

I created one, see bug #62189.

Back to xkeyboard-config: Karl Pentzlin was so kind to explain me how level/group selection works.  In XKB terms:

- The right Alt key pressed by itself can be both a Level 3 latch or a Level 3 switch, the standard does not dictate it.

- The Shift level of the right Alt key is a Level 5 latch (that is, it selects the "common secondary group")

- Level 3 of the Shift keys is a Level 5 latch as well.

- The standard does not dictate how the Caps Lock key should work.

The bug in the server I mentioned in comment #3 will be fixed in version 1.15.  Therefore, I will defer implementation of the correct level selection until after the May release is out.

Created attachment 83588 [details] [review]
Fixes to DIN T3 layout

These are the outstanding fixes for proper level selection of de(T3). They require server 1.15, which should be out at the time the next xkeyboard-config release is due.

Committed! Thanks.

About that AltGr-Latch: is that really necessary?

I find it pretty disturbing… When typing something, prior to perhaps entering \, {} or [], I let my thumb rest on the AltGr key, only to not type that character eventually, then continuing for example with ‌the 'c' key, and instead I get ©.

The reasoning in the document http://http://www.pentzlin.com/ErweiterungDeutscheTastatur2.pdf, §3.1 writes "Die AltGr-Taste wird von zahlreichen Software-Anwendungen für Steuerfunktionen verwendet", which is simply not true. No application in their right mind would AltGr+<key> for a special function, since the AltGr key isn’t even available on the US keyboard layout, which is pretty much the lowest common denominator.

Also, I don’t really know how many actually use T3 layout (I use it both at home and have successfully petitioned for it at work), so I don’t know how large the impact really is.

I therefore suggest changing this to:

183c183
<     key <RALT> { [ ISO_Level3_Latch, ISO_Level5_Latch, ISO_Level5_Latch ] };
---
>     key <RALT> { [ ISO_Level3_Shift, ISO_Level5_Latch, ISO_Level5_Latch ] };

(restoring the behavior people are used to).

I even use another extension (that could be optional), mapping RWIN to ISO_Level5_Shift, practically misusing the right super key as group selector (as in the Canadian Quebec keyboard).

I do not have any opinion. Denis? Andreas?

I do not have an opinion either, as I do not use the layout myself.  In favor of the proposed change, to the best of my knowledge, the behaviour of AltGr currently implemented is not a requirement of the standard, but merely a proposal of one of the main designers of the layout.  I also doubt that the layout is used much, so the number of people affected should not be large.

On the other hand, as Alexander already uses RWIN to access the "secondary group", for him, it should work to just use option lv3:ralt_switch to get back the usual behaviour of AltGr.  Alexander, would that be fine for you?

In any event, if the current behaviour is changed, we should add an option to get it back.  These latches are a clever idea, even if not everybody can get along with them.

@Andreas Wettstein: you write:

On the other hand, as Alexander already uses RWIN to access the "secondary group", for him, it should work to just use option lv3:ralt_switch to get back the usual behaviour of AltGr.  Alexander, would that be fine for you?

I’m not completely sure I understand what you mean by that sentence. DO you mean get back to the original behavior of AltGr (as a switch, not a latch)? Or do you propose something else.

As my second suggestion of using RWIN to switch to secondary group, I’m aware that is probably not really usable for all applications, as some keyboards (mostly laptops) do not even always have a RWIN key.

> I’m not completely sure I understand what you mean by that sentence. DO you mean get back to the original behavior of AltGr (as a switch, not a latch)?

Yes, that is what I mean.

Then I’m all for it!

Now it is Shift in git. Please check

*** Bug 99727 has been marked as a duplicate of this bug. ***

Gentlemen, the last commit created troubles. Should I revert or not?

https://cgit.freedesktop.org/xkeyboard-config/commit/?id=e38066c5c1bc2e72d78809da8ab241db00d9b78e

This can be easily fixed. You have to use ISO_Level3_Shift instead of ISO_Level3_Switch.

Created attachment 129433 [details] [review]
Fixed RALT config of de(T3)

Yes technically it is trivial. I just want all participants to be happy about it.

hey guys, i originally had problems with the 2.20 release because it broke the AltGr key on my german layout. i can confirm that the most current patch https://bugs.freedesktop.org/attachment.cgi?id=129433 doesn't have this problem anymore.

I am fine with the change.

On 21 Feb 2014, several patches by Ran were merged.  If I remember correctly, he had found those errors with a syntax checking tool based on xkbcommon.  Do I remember correctly?  And if yes, could this tool be used to check xkeyboard-config before releases?

What's the status on this? de(T3) is hardly usable without the fix...

(In reply to Moritz Sichert from comment #27)
> What's the status on this? de(T3) is hardly usable without the fix...

Thank you, committed! Sorry for delay

has this recently been changed? the symbols directory doesn't exist anymore, and the AltGr key is not working anymore (I'm using the kbd package from my opensuse system, version 2.0.3, built April 30, 2017.

It appears the entire thing has been majorly overhauled...

Ok, my previous comment was because the latest patch wasn’t committed yet.

DIN 2137-2 has already been implemented on Windows by its designer:
http://europatastatur.de
The group selector is now AltGr + B03, that is the ⌀ sign (hijacked).
This is a group selector dead key (= a remnant group selector, or latching).
A group selector modifier key on Right Control is against the spec, which 
is backwards compatible. BTW the ISO/IEC 9995 standard specifies such a key as being next to AltGr: “Optionally, if one key can be dedicated to the Group select function, in this case it is recommended to be placed adjacent to a Level 3 select key.” 
http://web.archive.org/web/20070719075251/http://cyberiel.iquebec.com/sc35wg1/sc35n0232_9995-2.pdf

Iʼd suggest that XKB stick with that implementation. The standard is currently under revision, however. While theyʼre on it, Iʼd suggest that the group selector dead key be placed on the spacebar, on “level 3” i.e. AltGr/Option + Space. NBSP can be raised by one level (Shift + AltGr + Space; prohibiting that level is now a pointless remainder of initial design). See http://unicode.org/pipermail/cldr-users/2018-February/000731.html

(In reply to Alexander Roalter from comment #13)
> The reasoning in the document
> http://http://www.pentzlin.com/ErweiterungDeutscheTastatur2.pdf, §3.1 writes
> "Die AltGr-Taste wird von zahlreichen Software-Anwendungen für
> Steuerfunktionen verwendet", which is simply not true. No application in
> their right mind would AltGr+<key> for a special function, since the AltGr
> key isn’t even available on the US keyboard layout, which is pretty much the
> lowest common denominator.

When I used the style separator in Word, whose shortcut is Shift+Ctrl+Alt+Enter, 
I could press as well Shift+AltGr+Enter. (But when Iʼd mapped a character to AltGr+Enter for test purposes, that ceased.) The way Word handles key combos is to merge Ctrl+Alt and AltGr whenever there is only either an application shortcut with Ctrl+Alt, or a layout mapping with AltGr. When both are competing, AltGr is dedicated to the graphic, while Ctrl+Alt invokes the shortcut.

As of how many applications do handle key combinations this way, Iʼve got no information because I donʼt use “numerous” applications. Given thereʼs at least one, Karl Pentzlinʼs statement is not untrue. 

And I think an application handling key combos this way is in its very “right mind”, since on Windows, the AltGr key basically has ever been a shortcut for Ctrl+Alt. Donʼt forget Pentzlin is talking about Windows, not Linux.

And LibreOffice / OpenOffice donʼt do this distinction, they always prioritize the AltGr = Ctrl+Alt equivalence. When there is both a character and a shortcut, weʼre unable to type the character unless we disable or remap the shortcut. Both productivity suits together are already a dozen or so applications, so we donʼt need to extrapolate as much to confirm Karl Pentzlinʼs statement. BTW heʼs a computer scientist so you can trust him. And again, heʼs talking about Windows, so telling that this is “simply not true” on Linux is just to remember AltGr is better implemented on Linux than it is on Windows, isnʼt it?

(In reply to Marcel Schneider from comment #33)
> And LibreOffice / OpenOffice donʼt do this distinction, they always
> prioritize the AltGr = Ctrl+Alt equivalence. When there is both a character
> and a shortcut, weʼre unable to type the character unless we disable or
> remap the shortcut.
Oh sorry, itʼs the other way around. Just tested in OpenOffice Writer. Ctrl+Alt+V is special paste and works with all layouts that have not a character on AltGr+V. Now enable any of the following keyboards: Albanian, Croatian, Finnish with Sami, Hungarian, Hungarian 101-key, Inuktitut - Latin, Inuktitut - Naqittaut, Latvian, Norwegian with Sami, Polish (214), Romanian (Legacy), Serbian (Latin), Slovak (QWERTY), Slovak, Slovenian, Swedish with Sami, Czech, Turkish F, Vietnamese. All having a character on AltGr+V. I’ve tested with Romanian, where we have @. Now when I type AltGr+V in OpenOffice I get @. Thatʼs fine (with US-Intl it opened the special paste dialog when typing AltGr+V, because on that layout, the AltGr map has large holes, including V). But when I press Ctrl+Alt+V, I get the at sign too!

(In reply to Alexander Roalter from comment #13)
> […] the document
> http://http://www.pentzlin.com/ErweiterungDeutscheTastatur2.pdf, §3.1 writes
> "Die AltGr-Taste wird von zahlreichen Software-Anwendungen für
> Steuerfunktionen verwendet" […]

The link has got messed up.
http://www.pentzlin.com/ErweiterungDeutscheTastatur2.pdf
is live (broken link redirects to providerʼs homepage).

Marcel, I am confused about what you concern is.

Do you want to have a latch to the secondary group on AltGr+Space?  As this is an explicit violation of the DIN 2137-T3 standard (which demands that AltGr+Space is a non-breaking space), is suggest you open a separate ticket for implementing your desired behaviour as an option.

Or do you see a violation of the DIN 2137-T3 standard in the xkeyboard-config’s current implementation?  The current implementation uses Shift+AltGr to activate a latch to the secondary group, which, to the best of my knowledge, is what the standard requires; see comment #10 and comment #11.

(In reply to Andreas Wettstein from comment #36)

Sorry, Iʼve got no means to test how XKB works with the German T3 and regret not having managed to take an in-depth look into the environment. Based on what I can test on Windows and what Iʼve been given the opportunity to test on macOS, neither of both supports the extra behavior ISO 9995 invented, but indeed XKB does, as I can see now from your attachment 83588 [details] [review]. I missed completely the point when I went through this thread. Because I never imagined that XKB treats modifiers by levels as it does for graphic keys.

Now my remaining concern is why ISO wanted a standard that is not cross-platform implementable, breaking UX as people switch back and forth between workplaces. And how they want us to properly implement on Windows and Mac OS X, layouts like the German T3, that is of course not going to stand alone in the landscape. France is actually standardizing two layouts, and that shall be our national keyboard standard. We donʼt want it not to be implementable on Windows and macOS, but we donʼt want it to be a flat fallback neither. 

I was always sure that Linux developers are free and clever and have resources to do whatever they want (but never checked out how it works in practice for the T3), so the point is to get something that will work on Windows and the Mac.

Any hints? 
But OK thatʼs definitely up to the standards people.

Thanks,
Marcel

sove thus

hello

hello