In Unicode there is a strict convention, for both Hebrew and Arabic:
The character for open braces is the same as in English, and the same with
"close braces", and it mirrored in the display.
** Standard "English" keyboard layout, Shift+9 creates (, ASCII code #41
and Shift+0 creates ), ASCII code #41
* In Hebrew keyboard layout, Shift+0 creates ASCII #40 [open] and Shift+9
creates #41 (close)
* Unicode algorithm switch the screen-display of many characters according
to the "general" direction.
List of mirrored-chars from Perl's Unicode library:
http://perl5.git.perl.org/perl.git/blob/HEAD:/lib/unicore/BidiMirroring.txt
The mirroring part of Unicode standard:
http://unicode.org/reports/tr9/#Mirroring
Unicode is the same for Hebrew and Arabic.
So, proper unicode text is
Hebrew #40 Hebrew #41 Hebrew
(and the same for Arabic)
LaTeX\PDFLaTeX needs to get ASCII#41 for open Hebrew brace and #40 for
close Hebrew brace.
For Arabic, (according to LyX's pdf-latex output), Same as Unicode: #40
open and #41 close.
BUT! for other type of braces: for example, angle, "<"=#60 ">"=#62,
So, in Arabic, as in Hebrew, One opens with #62 and close with, #60.
I'm not sure how the PDF produced by this convention look like, as
texlive-lang-arabic (debian) is not sufficient to compile it. I'll assume
that lyx produce proper output. s
Example text with these conventions:
hebrew #41 hebrew #40 hebrew #62 hebrew #60 hebrew
arabic #40 arabic #41 arabic #62 arabic #60 arabic
XeTeX conforms with Unicode (#40 to open and #41 to close,
display-direction defined by the surrounding language)
In LyX:
* Hebrew: Shift+0 = "open" = #41. Shift+9="close" =#40.
* Arabic: Shift+0 = #40, but LyX draws it as #41, according to Unicode
standard. Shift+9=#41, but LyX draws #40.
So, this is weird!
It seems like Arabic-regular-tex format is inconsistent: the behavior of ()
is different then the behavior of <>. Further more, the char display on the
screen when one type Shift+9 or Shift+0 is opposite to the one on (my)
keyboard.
In any other aspect, Arabic and Hebrew in LyX are the same, and opposite
from Unicode.
I'm not sure how one can solve the mess:
One option is to make LyX editor full Unicode complaint. I'm sure it will
require a lot of work, file-format change and non-trivial conversion. and
then, only the-non-polyglassia output will have to switch the braces
backwards.
Other options is just keep patching the different kind of Unicode-outputs,
the same is done in bug #8251 (And it seems that solving #8278 will be more
complicated, as no one around the xhtml exporter uses BufferParams, so it
will be a long way to carry it.
Ronen.
On Sun, Jul 29, 2012 at 12:32 PM, Jürgen Spitzmüller <sp...@lyx.org> wrote:
> 2012/7/28 Ronen Abravanel <ron...@gmail.com>:
> > When I'm typing Hebrew, I want to open braces by typing Shift+0 and
> close
> > by Shift+9
> > When I'm typing English, I want to open braces with Shift+0 and close
> with
> > Shift+0
> >
> > I'm not sure what you mean by "correct input" .
>
> I suppose there might be arguments for both ways, depending on the
> perspective. The current "Hebrew" way (in LyX) is to get on screen
> (and in the output) the parenthesis in the form it is represented on
> the keyboard -- i.e.: if I press ")", I want to get ")".
>
> The current "Arabic" way could be oriented on the (Western) semantics
> of the glyphs: The "(" key produces an opening parenthesis, both in
> LTR -- "(open..." -- and in RTL -- "...nepo)". But this is just me
> guessing wildly.
>
> What is inconsistent in the "Arabic" way, at least, is that it only
> concerns (round) parentheses. All other brackets -- [], {}, <> -- are
> handled as in Hebrew, and they are also stored reversed in the LyX
> file (as in Hebrew).
>
> Jürgen
>
