[sil_hebrew] Problem using parenthesis with Keyman Hebrew (SIL) about keyboards HOT 10 CLOSED

I assumed that this was a Mac-specific issue, but when I type in keymanweb.com, I see the same output as for TextEdit on the Mac. Does this work correctly for Keyman in any platform? Is it something that can be addressed in Keyman Core?

from keyboards.

Copying this from the discussion on Keyman community because it is pertinent.

Yes, @andjc is right; I should have picked up on this earlier. It's almost certainly to do with the way that macOS renders the parentheses, rather than a bug in Keyman for Mac's text output. If you want to have a fun reading day, read the W3C's overview of the Unicode Bidi Algorithm (and if you want to have a scary day, read the algorithm doc itself!)

Suffice to say, this is one of those areas where behaviour differs across programs and platforms as well, so you may get mirrored parentheses (or you may not), and the direction of the parentheses may be determined by the words surrounding it, the underlying paragraph direction, or even by whether or not Hebrew support is enabled for the application, in some cases. The implementation of the Bidi algorithm is not terribly consistent, sadly.

FWIW, the SIL Hebrew keyboard emits U+0028 (open parenthesis), for Shift+0 ()) and U+0029 (close parenthesis) for Shift+9 ((). This is more than a little confusing to parse in the keyboard source when you dig, but it does mean the symbols printed on the US keyboard key cap match what you see on the screen -- so WYSIWYG for the end user...

 + "("		> U+0029  c d41	close paren	2/10/97
 + ")"		> U+0028  c d40	open paren	2/10/97

Interesting historical note, I see @andjc ported sil_hebrew to our git repo 😁

from keyboards.

from keyboards.

[>][space][left paren][>][right paren]

This is the crux, what is meant by [left paren]?

[SHIFT K_0] types the opening parenthesis (left parenthesis) and the key to the left [SHIFT K_9] types the closing parenthesis (right parenthesis), i.e bidi mirroring should occur.

But text layout direction you are typing into is a critical factor, you need to be in an RTL editing environment. If the editing environment is using first strong heuristic, it is critical that the first character with a strong directionality is right to left.

from keyboards.

In the issue two screenshots are included.

For both TextEdit and Pages, it appears that closing parenthesis was typed before the aleph, and opening parenthesis typed after it.

For Pages, additionally the RTL string is being displayed as a LTR string. Probably a settings issue.

from keyboards.

I am guessing that the first paren in the Pages image is getting LTR directionality from the space (i.e. para direction) and the second paren is getting RTL directionality from the Aleph, which is why they both appear the same? Weird if true but seems likely.

from keyboards.

@mcdurdin Not weird, just an issue of what embedding levels each character is assigned to, as you surmise the first paraenthesis follows a space and inherits LTR from its context and is not mirrored. The second parenthesis follows directly after a strong RTL character and ends up in a RTL embedding, and the glyph therefore gets mirrored.

So we have an unmirrored closing parenthesis and a mirrored opening parenthesis, so both end up facing the same way. The fun of the bidirectional algorithm, and illustrates very well why getting the base direction of text right is critical.

If I try the same in a browser, I get the same results. Including in the source code:

<div class="sample" dir="ltr">א )א(</div>

from keyboards.

@mcdurdin Is there clarity on what to do with this issue?

• Is there something to fix in the keyboard?
• Is there something to add to the documentation for the keyboard?
• Is there something to change in the Keyman engine(s)?
• Do we just close the issue?

from keyboards.

@DavidLRowe the keyboard behaviour wrt parentheses appears to be identical to the system keyboards I have tried.

from keyboards.

I think this is by-design for the keyboard. On macOS, we have a limitation re RTL keyboards which needs to be addressed, but we already have two issues relating to that:

• keymanapp/keyman#170
• keymanapp/keyman#2237

(Yes they are very old issues, welcome to the reality that we have not had a mac developer until @sgschantz joined the team!)

from keyboards.