I use Keyman with Hebrew (SIL) on a Mac with OS 16 and Word 16.69 (365 subscription). When trying to type a Hebrew word inside parenthesis, the closing parenthesis "jumps’ out of place. I’ll type a word and then try to put an alternate word in parentheses. After spacing between words, I’ll type the open parenthesis, which makes that character jump to the right margin of the line. I’ll type the first Hebrew character of the word I want in parentheses, and that letter plus the open parenthesis jumps back into place. I’ll type the rest of the word, and then when I type the closing parenthesis, that character jumps to the right margin again. I have tried several iterations and “tricks” to get this to work, but I cannot simply type a Hebrew word inside parentheses. Any help?
UPDATE - a few more details. After typing a word (Hebrew 1st person pronoun), I entered a space, typed the open parenthesis, and the “)” character (which is the opening parenthesis for Hebrew) aligned on the right margin. The alignment is set as right aligned. I then typed the longer spelling for the pronoun, and after typing the first character (aleph), that character and the opening parenthesis moved to the left of the first word, continuing as it should after the first word with a space between. I then typed the rest of the pronoun and typed the close quote character “(”, and it jumped to the right margin also. NOTE: on the Hebrew keyboard, typing the English open paren character “(” outputs the Hebrew open paren character “)” as it should. I then typed another space character and entered another letter, aleph again in this case. As soon as I typed that character, the close quote and the new aleph character moved to the left of the word I’m trying to enclose in parentheses. The output produced a space after the second word, the close paren, and the next letter with no space between the close paren and the aleph I typed.
Welcome to the community, @mcb.
I am sorry that you have to deal with this issue, but I do not know enough to help with this issue as it is highly language specific. Hope others can jump in to help.
Hello @mcb, could I get some additional information from you to help investigate this issue?
-
Please provide the minimal keystrokes that I would type on a US keyboard to reproduce the problem. (This will help make up for the lack of Hebrew knowledge on our team.)
-
I don’t recognize the MacOS version number. What version info do you see when you select About This Mac under the Apple menu? Also, what version of Keyman are you using?
-
Do you see a different result if you type the same characters in another text editor that comes with your Mac, such as Pages or TextEdit?
Thank you for your response, and I apologize for taking a few days to reply. I’ve been sick.
-
The minimal keystrokes to duplicate what I’ve been experiencing would be these: >, [space], (, >, ). That will result in an aleph character, a space, open parenthesis, aleph character, close parenthesis.
-
Here is an image of my Mac’s info:
The version of Keyman is 15.0.274. -
I see the same kind of problem with Word and Pages, although Pages behaves slightly differently. When I typed these same characters in TextEditor, everything worked the way it should. I hadn’t tried that before.
Thank you again for your response.
Michael Beard
Hi Michael,
I’m sure that Keyman for Mac is not producing the correct output for Hebrew, but I think I need to clarify a little further.
If you type the following, in order from left to right:
[>][space][left paren][>][right paren]
Do you expect to see the following output?
א (א)
For TextEdit, I see:
and for Pages, I see:
Thanks for your patience and sorry for the delay in getting back to you.
Shawn
This topic is scheduled to be closed three weeks from now. Please reply before then if you need further assistance.
Hello! The end of semester kept me away from this for quite a while. Apologies. I followed your keystrokes, expecting to see the first output you listed (answering your question, “Do you expect to see the following output?” - yes, that’s what is expected. The output, however, was what you displayed for Pages. In both Pages and Word, that’s the result I get. Thank you!
I’ve created an issue for this at [sil_hebrew] Problem using parenthesis with Keyman Hebrew (SIL) · Issue #2247 · keymanapp/keyboards · GitHub.
Let’s track it there.
Sounds like an issue with Word or macOS. It is also important to remember parenthesis are mirrored, on top of this the system layout on macOS show the mirrored parenthesֶs not the LTR view. The right most key usually types the opening/left parenthesis.
aleph + space + left parenthesis (opening parenthesis) + aleph + right parenthesis (closing parenthesis) works as expected.
One thing worth noting, on Word on my mac, typing directly from keyboard works correctly, and generates the correct sequence, but if I paste in Hebrew text into Word, the results are unpredicatble, the mirroring of the parentheses sometimes gets broken. I need to dig further into this when I have time. Pasting text only is a bit more reliable. I need to explore further.
Yes, @Andrew_Cunningham 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 @Andrew_Cunningham ported sil_hebrew to our git repo 
@Marc I think it may be worth going through the various RTL layouts to optimise the OSKs so it is more apparent to users what is happening. Also whether the mirrored version of the glyph is displayed on the OSK. I find a useful approach is to have the opening parenthesis to the right and closing parenthesis to the left of each other.
Also I tend to use logical descriptions these days, the Unicode characters in question are left and right parentheses, but logically are best referred to as opening and closing parentheses.
+ "(" > U+0029 c d41 close paren 2/10/97
+ ")" > U+0028 c d40 open paren 2/10/97
Essentially, this is just swapping the keys, moving opening to the right, and closing the the left, and OSK display matches.
Context is critical. whether the overall direction is RTL or LTR, whether first strong heuristic is being used, whether the overall direction of string is LTR or RTL, whether isolation embeddings or simple embeddings are also being used. And different applications and different versions of different applications …
Even more fun for newly encoded RTL scripts, where bidi support may not have propagated down to user applications yet.
I think this is by-design for the keyboard. On macOS, we have a limitation re RTL keyboards which needs to be addressed, and we already have two issues relating to that:
- [Mac] RTL does not appear to be triggered in Word 2016 keyman#170
- [Mac] Can we do language tagging? keyman#2237
So that’s probably the best we can do for now – until we get the space to address the Keyman for mac limitations.