bug(sil_hebrew): missing labels on keys of OSK (on screen keyboard)

[sze2st]

Describe the bug

On screen keyboard (OSK) shows key without any label which is unexpected

Reproduce the bug

Issue is reproducible using e.g. keyman 19.0.249.0-alpha on Windows 10 as follows

1. Start keyman configuration
2. download keyboard sil_hebrew and install it
3. open editor e.g. Notepad++
4. Open on screen keyboard (OSK) and select Ancient Hebrew (hbo-Hebr-IL) Hebrew (SIL)

5. click key j on OSK: results in שׁ (i.e. hebrew letter shin)
6. click key Right Alt on OSK: results in changing the labels on the keys, note that key o is not labeled at all whereas key 1 is labeled with ֽ

7. click key o on OSK (while Right Alt is still in use). result: שׁis changed to שׇׁ i.e. vowel sign "qamats" is added below the letter shin. This shows that although OSK shows key o as being unlabeled anyway a unicode is assigned to it.

Get detailed description of sil_hebrew keyboard by clicking ? on OSK: results in new window Keyman Help. Click on link to help for Hebrew (SIL) keyboard: results in window with detailed description of Hebrew (SIL) keyboard. It shows Right Alt mode as

i.e. key o is labeled with qamats vowel sign which has unicode 05C7. This corresponds to what happens when clicking Right Alt + o

Expected behavior

Right Alt mode of OSK should label key o with qamats vowel sign ׇ (i.e. unicode 05C7)

Related issues

No response

Keyman apps

• Keyman for Android
• Keyman for iPhone and iPad
• Keyman for Linux
• Keyman for macOS
• Keyman for Windows
• Keyman Developer
• KeymanWeb
• Other - give details at bottom of form

Keyman version

19.0.249.0-alpha

Operating system

Windows 10

Device

Windows Lenovo ThinkPad

Target application

No response

Browser

No response

Keyboard name

sil_hebrew

Keyboard version

No response

Language name

No response

Additional context

No response

[mcdurdin]

I think this relates to the sil_hebrew keyboard rather than Keyman for Windows, so will transfer to the keyboards repo for investigation (if it turns out to be a Keyman for Windows bug we can move it back again!)

[darcywong00]

The .kvks file already includes right-alt K_O

keyboards/release/sil/sil_hebrew/source/sil_hebrew.kvks

Lines 95 to 109 in 7cccb86

	<layer shift="RA">
	<key vkey="K_BKQUOTE">$</key>
	<key vkey="K_1">ֽ</key>
	<key vkey="K_2">֢</key>
	<key vkey="K_3">֖</key>
	<key vkey="K_4">֥</key>
	<key vkey="K_5">֦</key>
	<key vkey="K_6">֭</key>
	<key vkey="K_7">֣</key>
	<key vkey="K_8">֛</key>
	<key vkey="K_9">֧</key>
	<key vkey="K_0">֪</key>
	<key vkey="K_HYPHEN">—</key>
	<key vkey="K_EQUAL">֑</key>
	<key vkey="K_O">ׇ</key>

Do we know if the OSK Font KbdHebr-Regular.ttf handles U+05C7?

[LornaSIL]

This is confusing to me. Before we had this remapping scheme I would put U+25CC in the string. So, since we created KbdHebr.json based on existing keyboards, we have this in the .json file:

    {
      "pua": "F15A",
      "str": "◌ׇ",
      "unicode": "25CC 05C7",
      "usages": [
        "sil_hebrew.kvks",
        "sil_hebrew.keyman-touch-layout",
        "sil_hebrew_legacy.kvks",
        "sil_hebrew_legacy.keyman-touch-layout"
      ]
    },

Does that mean it only displays that on the keycap if the 25CC is in the string? If so, we need to make changes to add 25CC back into the OSK?

One reason I could/should keep 25CC in the string is that it helps create the graphics for welcome.htm file.

I suppose a solution would be to duplicate the above code, but remove the 25CC so that it displays whether there is a 25CC in the string or not?