Null character U+0000 issue

[ClavierPixelKey]

I do a lot of custom keyboard layout designing and I experimented with using U+0000 in the dead key tables, thinking it can work as some sort of autocorrection system. Unfortunately this emits an error sound in Windows Notepad.

ALTGR+H, ALTGR+H

Also, I don’t understand why there is a null character st ALTGR+SHIFT+E which doesn’t do anything.

[springcomp]

The NULL character can be used as a dead key trigger, but only once. This is useful if one of the positions must be used in a dead key table but not on the main layout.

As explained at the end of the documentation, a dead-key followed by an key that does not have a mapping is guaranteed to emit the character associated with the dead key.

The AltGr+ShiftE is an error that I'm trying to fix (see #90) but I have not found the right combination yet.

As you know, the following combination: AltGr+g, AltGr+ShiftE should produce the currency sign. However, this means that there should be a 'source mapping' corresponding to the AltGr+ShiftE combination.

That is why I chose NULL.

Unfortunately, you are right in that it seems to produce the ding sound.

[ClavierPixelKey]

Sorry I don't understand… Why not just remove all of the null characters? And which currency sign? ¤ or ₠ or € ?

ALTGR+SHIFT+E is the null character, but set as a dead key.

DEADKEY 0000

0045 00a4 // E -> ¤

There's also another batch of null characters in the EU dead key table named with the long s ( ſ ). If i understand correctly, you are finding ways to make sure that ſ does not appear even after pressing EU + SPACE.

I'm wondering, how do you visually represent (highlight) keyboard keys like ALTGR + A B C in text to demonstrate clearly which key to press? It's easier to read.

[springcomp]

In GitHub comments, you can type

<kbd>Key Name</kbd>

And it gets translated to a nice Key Name string.

As for your question:

The Unicode character ¤ is the [CURRENCY SIGN] (U+00A4). The standard has assigned this character to the position AltGr+¤, AltGr+Shift+e on the Supplementary Monetary Signs layer.

The way dead-keys work means that the second character from the sequence above must exist, in order to appear in the source character in the dead key table corresponding to the ¤ layer. So this character must be assigned a Unicode code point. However, we do not want this character to output anything when used by itself on the main layer. That is AltGr+Shift+e should not produce any output.

That's why it is a dead key.

Because it is a dead key, there must be a dead key table in the layout for it. I chose a single dummy entry with, for the 0000 dead key table as you have seen.

Unfortunately, the character being assigned to emit a NULL means that's ding sound is heard when using Notepad and, possibly, other editors.

In the end, this is a hack to try and be compliant with the standard, even though the character can be input using the simpler, but not standardized sequence:AltGr+¤, Space.

[ClavierPixelKey]

In the end, this is a hack to try and be compliant with the standard, even though the character can be input using the simpler, but not standardized sequence:AltGr+Eu, Space.

Um… I think you meant AltGr+f, Space → ¤

AltGr+Eu, Space is the Eu key ſ and it is not related to the ¤ currency dead key table.

If it is really a must that AltGr+¤, AltGr+Shift+e to output ¤ then I think the easiest solution is to duplicate€ or ¤ or even E at AltGr+Shift+e. Or don’t make AltGr+¤, AltGr+Shift+e at all (because it’s already easy to type ¤)

In any case we should get rid of the null character.

[springcomp]

Um… I think you meant AltGr+f, Space → ¤

Yes, my mistake. I edited the previous comment for clarity.

If it is really a must that AltGr+¤, AltGr+Shift+e to output ¤ then I think the easiest solution is to duplicate€ or ¤ or even E at AltGr+Shift+e. Or don’t make AltGr+¤, AltGr+Shift+e at all (because it’s already easy to type ¤)

Well, that’s the difficult balance I’m trying to make.

I take great pride in having the most standard-compliant driver. So, the question is to define priorities.

My priorities are as follows:

• Make the layout comply to the standard as much as possible.
• Make the layout easy to use by leveraging existing behaviour as found on the traditional AZERTY (where the standard gives some latitude) and people’s habit.
• Reduce the amount of undesirable characters that may be output by the layout.

In the end, I have tried various approaches (see #90) but, so far, I have found the result worst that the current situation - in terms of behavior and in terms of future maintenance of the layout file.

Currently, we can observe that there is a ding in Notepad. So far, this is the only application where this happens. It does not beep in Microsoft Word, neither does it beep in Visual Studio, Visual Studio Code, NotePad++, etc.

So, I think the current situation is the least bad given the constraints 😥.

You are suggesting that the sequence AltGr+Shift+e may output € or E to help achieve my results without producing a nasty beep sound. However, one must choose a different code point, that is not already present on the main layout.

• e is already used as a source mapping for a currency.
• E is not, but then, this would mean producing the currency sign with AltGr+e (without Shift)
• ¤ is not, but then, this would mean producing the currency sign with AltGr+¤ (back to square one ☹️)

[ClavierPixelKey]

How about AltGr+f, Shift+e = ¤ instead of AltGr+f, AltGr+Shift+e = ¤?

Same method for ₯ and ₤. No undesirable characters and it is more in line with the other monetary symbols in the dead key table.

Unfortunately the ding sound can really make people think there’s something wrong with the keyboard layout or their program. It seems to be that a basic text editor like Notepad doesn’t understand NULL °°/

As for the Eu key, I think it’s no problem that AltGr+h, Space outputs ſ right?

[ClavierPixelKey]

How about AltGr+f, Shift+e = ¤ instead of AltGr+f, AltGrShift+e = ¤?

My goal is to provide a standard compliant driver. And the standard says where the currency sign should be.

Unfortunately the ding sound can really make people think there’s something wrong with the keyboard layout or their program. As for the Eu key, I think it’s no problem that AltGr+h, Space outputs ſ right?

I accept that a ding sound be heard if the user presses an illegal sequence. On that does not produce a character. It's not nice, but at least, it is consistent.

As a regular user, if I press, say, a ^ by mistake on a traditional AZERTY keyboard, followed by b, I'm not surprised to see the string ^b.

Likewise, if I press AltGr+¤ or AltGr+μ by mistake on a new AZERTY-NF keyboard, followed by q, I would not be surprised to see the the text ¤q or μq displayed.

However, if I were to press AltGr+Eu by mistake, followed by q, I would definitely be very surprised to to see the string ſq displayed!

Correct me if I’m wrong but what if the standard is supposed to be ¤ = AltGr+f, Shift+e but instead they’ve made a slight oversight and instead defined ¤ = AltGr+f, AltGr+Shift+e?

You’re right, ſ is a weird archaic character that might create some surprises if it appears out of nowhere. The problem is that if we put NULL to the Eu dead key table everywhere to make sure ſ doesn’t appear there will be a lot of NULL. And ideal solution would be one Unicode symbol that looks like Eu and is supported in most fonts. Should we try ℮ ESTIMATED SYMBOL (U+212E) instead, or perhaps ð? Something like ℮ popping up should not cause too much surprises because the H key is label “Eu”. Hmm… I checked how the ℮ appears in some fonts and Verdana makes it look like a simple enlarged e.

[springcomp]

Correct me if I’m wrong but what if the standard is supposed to be ¤ = AltGr+f, Shift+e but instead they’ve made a slight oversight and instead defined ¤ = AltGr+f, AltGr+Shift+e?

Unfortunately, no they did not. It has been triple checked by @cyril-L.

However, if I were to press AltGr+Eu by mistake, followed by q, I would definitely be very surprised to to see the string ſq displayed!

As I typed this, I checked and, indeed, this is what happens! The string ſq is displayed! That's why I edited it out from my original comment.

In any case, it made me rethink.

I'll try and come up with sensible defaults that do not involve NULL characters from the Eu layer.

There is already a note about undesirable characters being displayed at the end of the documentation.

I'll make sure to explain the rationale.

However, I'm not too keen on removing support for the official currency sign position. Even it it dings.

After all, I expect the standard sequence of key presses to not be exercised very often, especially considering that there is a simpler sequence which is even more natural to Windows users.

[springcomp]

@ClavierPixelKey would you try this preliminary version and provide feedback?

[ClavierPixelKey]

Okay, I’ve tested it and the ¤ works! =) But the ſ no longer works at all; I can’t type the ſ nor the º.

May I know why Unicode character did you use?

One odd thing is that I can’t open load the keyboard with MSKLC (to quickly view the keyboard layout source code).

[ClavierPixelKey]

017f 0020 // ſ ->

Oh a normal space

Not sure if this is linked to the problem but I’m unable to make the touch keyboard show the 3rd & 4th levels (AltGr & AltGr+Shift) of all of my keyboard layouts, including AZERTY-NF and QWERTY. Strangely enough, the on-screen keyboard works and the Eu dead key also works…

[ClavierPixelKey]

I forgot to mention that I'm running the latest Windows 10 Home 1909 which now adds a new symbols & emojis panel (⊞ Win + .).

I’ll try to reinstall the keyboard layout again.

[springcomp]

Not sure if this is linked to the problem but I’m unable to make the touch keyboard show the 3rd & 4th levels (AltGr & AltGr+Shift) of all of my keyboard layouts, including AZERTY-NF and QWERTY. Strangely enough, the on-screen keyboard works and the Eu dead key also works…

Yes this is a know issue. If you have the Windows 10 Feedback Hub App you may see one of my comments about this. Basically, the on-screen keyboard does not work very well with the diacriticals of AZERTY-NF.

[springcomp]

Okay, I’ve tested it and the ¤ works! =) But the ſ no longer works at all; I can’t type the ſ nor the º.

Thanks for the feedback. I’ll have more time in the next few days for more thorough testing and report back.

[ClavierPixelKey]

Not sure if this is linked to the problem but I’m unable to make the touch keyboard show the 3rd & 4th levels (AltGr & AltGr+Shift) of all of my keyboard layouts, including AZERTY-NF and QWERTY. Strangely enough, the on-screen keyboard works and the Eu dead key also works…

Yes this is a know issue. If you have the Windows 10 Feedback Hub App you may see one of my comments about this. Basically, the on-screen keyboard does not work very well with the diacriticals of AZERTY-NF.

Sorry I wasn’t clearer. I mean that the On-Screen Keyboard (which shows the number pad) works completely fine (even the Eu dead key table works properly).

It’s the Touch keyboard (accessible via a button on the bottom right corner) that has a problem with the AZERTY-NF preliminary version (cannot display the keyboard at all).

The previous AZERTY-NF worked quite fine with the Touch keyboard (can press Alt+Ctrl virtual buttons to access the AltGr level). However, at that time I was running a previous version of Windows — Windows 10 Home build 1809.

[springcomp]

Not sure if this is linked to the problem but I’m unable to make the touch keyboard show the 3rd & 4th levels (AltGr & AltGr+Shift) of all of my keyboard layouts, including AZERTY-NF and QWERTY. Strangely enough, the on-screen keyboard works and the Eu dead key also works…

Oh my god! 😱 this release is sooooo buggy, it’s not even funny ! I re-installed the latest official version and all is well. I wonder how such few changes in the distribution can cause such bugs.

I’ll need to investigate more.

[ClavierPixelKey]

Creating and editing ⌨ layouts is not easy! ^^

One thing I know is that MSKLC does not accept Unicode characters with more than four code points (like an emoji). This also means adding the copyleft symbol U+1F12F is not compatible at all with MSKLC. I'm not sure how Windows handles it.

[ClavierPixelKey]

On-screen keyboard AltGr issue (might be related to the bugs in the AZERTY-NF preliminary version)

I’m running into a problem with my own custom layout called QWERTY+ International. The On-Screen keyboard (the one that shows the numpad) does not work properly out of a sudden. I thought it is due to a problem with a new version of my keyboard layout, but all of my old ones suddenly have a problem with the virtual AltGr key (it doesn’t appear). Curiously, when the AZERTY-NF (old version) and other keyboard layouts are selected, the On-Screen keyboard displays the ISO layout and the AltGr key just fine.

Pressing Alt and Ctrl doesn’t do anything. The Right Alt here is supposed to be displayed as the “AltGr” button.

As for the ⌨Touch keyboard, there are almost no problems with it. Interesting bug with the Touch keyboard: the extra ISO key never seems to show up in custom keyboard layouts, including the AZERTY-NF

Is this related to the new Windows 1909 update? I’m not even mentioning about the AltGr+Shift+F issue.

How frustrating!

[ClavierPixelKey]

Okay definitely a Windows 1909 issue. I don’t remember official built-in ISO layouts having problems with the On-Screen keyboard.

Adding any ISO keyboard layout already in Windows such as the Canadian QWERTY layout, German QWERTZ, UK layout — same issue. On-screen keyboard doesn’t work: clicking Ctrl and Alt doesn’t do anything, there’s no virtual AltGr button, and there’s no ISO key.

German QWERTZ layout:

UK ISO layout:

Oddly enough, the On-screen keyboard only works fine with certain layouts: French layouts like the AZERTY classique, AZERTY Belgique, AZERTY-NF, BÉPO, and other layouts like US-International.

FR AZERTY classique. ISO key <> is displayed and working.

US-International is a weird one, there’s no extra ISO key (even though it’s supposed to be a partial duplicate of the | key but AltGr still works.

It’s a hit-and-miss affair full of bugs. 🤔😒

[springcomp]

Thanks for providing feedback. I tried another update focusing only towards the currency sign but hit the bug you mention.

I'll try removing the currency sign entirely and focus on AltGr+Eu combinations to remove the NULL characters and see what I end up with.

[pieter-degroote]

I am working on a similar project which also uses AutoHotkey. AutoHotkey is an advanced scripting tool for Windows and allows you to modify the keyboard layout, and my project also has dead keys in that way.

https://github.com/pieter-degroote/UltimateKEYS  (the main repository)

https://github.com/pieter-degroote/UltimateKEYS-testing :  also contains alternate scripts for :

• AutoHotkey v2.0 alpha (tested with v2.0-a112)
• US-International as 'KBDUSX', since that layout has 'AltGr' instead of 'Right Alt'

A disadvantage of using AutoHotkey is that the 'on-screen keyboard' (or touch keyboard) does not work as expected... The main editions do not work with the 'Right Alt' (on the screen), while the operation of the KBDUSX editions do not correspond with the symbols displayed on the layout map. From the other side, I think that AutoHotkey can also open the doors for many new possibilities and avoid bugs (shortcomings) from older implementations (such as MSKLC 1.4).

[springcomp]

@pieter-degroote Indeed, AutoHotKey is a pretty useful tool. As far as I know it is being used extensively for the German neo keyboard layout that has seven layers. So a regular MSKLC-based driver would not be able to support most of what is needed.

Still, I think that with AZERTY-NF, I do not have to augment its shortcomings with AutoHotKey. The only thing that currently do not work would be the two-stages dead-key shortcuts, such as AltGr, i, AltGr, Eu, s to input ẛ.

But with my current user-base, I do not think this is a problem 😉

[springcomp]

Fixed by #133.