Aleph with Beth Hebrew: blank keycaps on app

Keyman
1

I’ve recently started using the Aleph with Beth Hebrew keyboard (v1.0.5, keyman 16.0, Win10 x64). It is brilliant.

The on-screen keys seem to be working correctly in the Windows app, but several keycaps appear blank. For example, “A”, “:”.

If I bring up the same keyboard in KeymanWeb, all the keycaps seem to display correctly.

Many thanks in advance if anyone can point to a solution/workaround.

2

I think it’s because no font is distributed with that keyboard so it is dependent on whatever font is installed.
We do seem to have issues with Hebrew keyboards and fonts and may try to address those soon.
It’s great to hear that particular “experimental” keyboard is so useful!

3

Thanks for the quick response!

I’m actually a retired programmer. I was able to clone the source and compile locally. I changed the font from “Arial” to “Times New Roman” and the keycaps look nicer, but still have the same blanks. The keyboard layouts in Help also have the same blanks.

I might browse around a little more. Perhaps I can offer some positive contribution to the effort.

4

Thanks for your interest! If you can find a font that works well for you on your system, that is great!

For a general solution, we’re looking at creating a special font that has all the character combinations so that we’ll get the same rendering on all platforms. To date we’ve found that certain fonts or workarounds display differently on different operating systems, thus making a general solution difficult without a dedicated font.

5

(update 12/28/23 21:46)
Just for comparison, I installed “Galaxie Hebrew (Mnemonic)” alongside. The layout seems a little less complete and convenient, but it displays everything as I expect. Diacritics are shown relative to dashed circles. In the sources: the .kvks file for Galaxie refers to font “Ezra SIL”. (As far as I can tell, this controls the keycaps.)

  • A somewhat uncomfortable workaround, without font changes, is possible: create/assign bitmaps for the problematic diacritic keycaps and recompile the keyboard. (I did a very quick test with a new dummy keyboard design.) Platform support is unknown.
6

I bit the bullet: I created 11 bitmaps for diacritics and fully rebuilt the keyboard package locally. It seems to work well. The .kvk file increased in size (770k).

I’m fully willing to share (in the spirit of open source).

7

Good work on the bitmaps!

You may be interested in seeing what we are introducing in Keyman Developer 17: generic keyboard key cap fonts that address inconsistency in diacritic and combining mark display across all scripts (including Hebrew).

An introduction to the broader problem and the solution we’ve landed on can be read in the spec issue #9031 and the documentation.

We also have a draft Hebrew (and Khmer) keyboard update for sil_hebrew at keyboards#2258, and we will go back and refresh that to include all the Hebrew keyboards in the repository once the Keyman Developer 17 compiler is active in the keyboards repository.

Reasons I like this solution include:

  1. It doesn’t require bitmaps, which are painful to maintain, don’t scale well, and can be inconsistent in display with other font-rendered characters.
  2. It is relatively easy to maintain, as the source keyboard does not require significant changes in order to resolve the problem.
  3. It is backwardly compatible with earlier versions of Keyman – we only need the compiler to be version 17 in order to support the &DisplayMap property.

Things that I don’t like as much:

  1. It’s a workaround for a renderer limitation – long term we want to resolve this problem entirely with updates to renderers, and are planning to submit a proposal to Unicode, but that will of course take years to filter down to all systems.
  2. The process of creating the display map itself with command line kmc and python tooling is fairly complicated and not very accessible to the average keyboard designer.

Once Keyman 17 is out, we plan to generate a KbdXxxx font for each affected script and include them in the keyboards repository. We have some process details to figure out on this, and some functionality that still needs to be completed, in particular #9767.

A long answer, but hopefully helpful :smile:

8

Thanks. The description in #9031 lines up with the gut feel I had (not having looked at any code). I’ve never taken off my analysis hat I guess… Best wishes on the implementation. I’ll stay tuned.

I’m a happy camper since my workaround wasn’t so painful and I am fully in business. What I learned of Keyman development was interesting and may come in very handy.

1 Like
9

This topic was automatically closed after 13 days. New replies are no longer allowed.