On behalf of user
It has been noticed that some key caps on the default layer of the Hebrew SIL keyboard appear empty, but they do output characters.
Keyman version: 16.0.37
iOS version: 16.3.1
Keyboard: Hebrew (SIL) keyboard
It is interesting though that they do show up in an older version of iOS,
iOS 16.3.1
Has anyone else encountered this issue? Have you found a way to resolve it?
Ok, the touch keyboard is using Ezra SIL.
Sometimes, the device can’t display diacritics properly if they don’t have a character to attach to. The keyboard includes an empty character (◌) U+25CC that precedes the letter which is not showing up here or on my machine for this keyboard. Keyman has been making changes in recent versions (and to the code) to make the diacritics show up better, and something might have gotten broken.
I just checked, and the font has and can display that character. It can display (◌) on a key by itself. Keyman is having issues merging U+25CC and the diacritic. It looks like maybe the empty character doesn’t combine/display properly in RTL. U+25CC is an intervening LTR character. For RTL languages like this one, it seems we need to add the RTL marker U+200F before to make “U+200F U+0255 Diacritic”. If we do that, it works properly. For those more familiar with RTL, I’m not sure if we need to add U+200E at the end so that XML document (which is LTR) doesn’t get broken.
@Lorna or @drowe, can one of you add U+200F before every U+25CC on the RTL keyboards? Otherwise, maybe the KM code needs to be updated to do that automagically.
~Matthew
The keyboard doesn’t output U+25CC, it’s just on the keycap for proper display. It might be better to just remove U+25CC than to try to do more stuff to make it appear better.
I understand why it’s on the Keycap, to give it something to hang on to.
When you add a 25CC manually on a LTR keyboard as was done here, it does display on devices (and this is what I prefer in my keyboard).
I think that the web logic is to choose the direction of the first character. This works for the base characters. It just fails to combine 25CC with a RTL diacritic without the 200F. The diacritic is landing off the key. It displays properly with the 25CC on devices if you add the U+200F to each display character.
It’s worth noting that the only thing that has changed here is the iOS version. Keyman hasn’t changed its presentation of the keyboard recently, and the Hebrew keyboard hasn’t changed either – it still displays just fine on earlier versions of iOS.
That said, 25CC has always been an unreliable method of giving a base to unattached marks, across many scripts. In fact, anything that relies on the renderer to do something consistent and sensible has been problematic, and behaviour differs across platforms and platform versions. For an example with Lao, see my blog.
It’s very likely that adding 200F to the OSK will cause it to break on other platforms, or even on other versions of iOS. Similarly, removing 25CC will probably cause marks to render off the key on some platforms.
The only way we have been able to make this work consistently everywhere is to create a custom font for the on screen keyboard which combines the dotted circle glyph (or anything, really) with each glyph that needs a base, each as its own PUA character. We do this for Lao and Khmer already – see khmer_angkor - #1710 for an example. Here’s the set of PUA characters we created for that keyboard – in each case, the dotted circle is a part of the glyph, not something added by a renderer:
We should probably consider doing the same for this keyboard. But is someone willing to create the OSK font based on Ezra SIL? (We no longer have someone on the Keyman team who can work on fonts.)
Yes, a font seems like a more long-term solution. I was looking at the short-term for a broken output.
No character may be an iOS-only error, but note that in the debugger and Android, the 25CC doesn’t show up as expected on keys with a RTL diacritic (it only shows the diacritic). This may be usable, but it’s not what the keyboard designer has defined.
I’d like to try and fix long-term rather than play whack-a-mole on platform support 
An issue has been created to track the progress of this fix: [sil_hebrew] · Issue #2172 · keymanapp/keyboards · GitHub.
See also:
This topic was automatically closed after 14 days. New replies are no longer allowed.
