Re: Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

On Fri, Jul 27, 2012 at 12:38 PM, Jürgen Spitzmüller sp...@lyx.org wrote:

 Guenter Milde wrote:
  I see, so we actually have
 
(siht)   for Arabic (babel  polyglossia) and Hebrew (polyglossia)
 
 as well as for Arabic and Hebrew in OpenOffice etc.
 
)siht(   for Hebrew (babel)

 Yes. In the LyX source file, that is. In the LyX workarea, we have (siht)
 in
 all cases.



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 .

Re: Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

On Fri, Jul 27, 2012 at 12:38 PM, Jürgen Spitzmüller sp...@lyx.org wrote:

 Guenter Milde wrote:
  I see, so we actually have
 
(siht)   for Arabic (babel  polyglossia) and Hebrew (polyglossia)
 
 as well as for Arabic and Hebrew in OpenOffice etc.
 
)siht(   for Hebrew (babel)

 Yes. In the LyX source file, that is. In the LyX workarea, we have (siht)
 in
 all cases.



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 .

Re: Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

On Fri, Jul 27, 2012 at 12:38 PM, Jürgen Spitzmüller  wrote:

> Guenter Milde wrote:
> > I see, so we actually have
> >
> >   (siht)   for Arabic (babel & polyglossia) and Hebrew (polyglossia)
> >
> >as well as for Arabic and Hebrew in OpenOffice etc.
> >
> >   )siht(   for Hebrew (babel)
>
> Yes. In the LyX source file, that is. In the LyX workarea, we have (siht)
> in
> all cases.
>
>

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" .

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-24, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 If I understand right, 

   babel converts the input )siht ekil( to (like this) 

 while

   xelatex+polyglossia converts (siht ekil) to (like this).

 Yes [for Hebrew, for that matter. In Arabic, the case is different. This is 
 why we have )siht( in the LyX source for Hebrew and (siht) for Arabic.]

I see, so we actually have

  (siht)   for Arabic (babel  polyglossia) and Hebrew (polyglossia)
   as well as for Arabic and Hebrew in OpenOffice etc.
  )siht(   for Hebrew (babel)

I would prefer if the LyX input were (siht) for both, Hebrew and
Arabic, regardless of the language package.

 IMO, this is a polyglossia feature. It may be regarded as a regression, if
 we fix it to behave like babel:

 However, the applied patch seems to do exactly this. Whether it is a
 fix or a regression depends on the use case.

  + documents written for babel also work with polyglossia,
  - text pasted from other applications now fails with both, babel and
polyglossia.

 Please correct me if I am wrong. 

 The patch does not touch the input (neither the input method nor the 
 representation in the LyX source and window), we just adapt the output if we 
 output to LaTeX with polyglossia. So I do not think anything will change 
 (except the output with polyglossia will be correct).

The patch changes the output, i.e. if someone uses the input convention
used in other Unicode editors and also in Arabic, the output will be wrong
with LyX. 

In this sense, it changes which input is required to get the correct output:

* You will get the correct output with polyglossia for documents intended for
  Hebrew (babel).
  
* You will get the wrong output with polyglossia for existing documents that
  used to work with Hebrew (polyglossia).

* You will get the wrong output with polyglossia for text inserted from
  OpenOffice or similar sources.  

It fixes one problem but creates two others, this is why I consider this
a regression.

A possible fix would be to toggle the parantheses whenever the document
settings change between use of babel and polyglossia or a function that
does so on user request. Also, the different input conventions and the
reasoning behind them should be documented.

Günter

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
 I see, so we actually have
 
   (siht)   for Arabic (babel  polyglossia) and Hebrew (polyglossia)
   
as well as for Arabic and Hebrew in OpenOffice etc.
   
   )siht(   for Hebrew (babel)

Yes. In the LyX source file, that is. In the LyX workarea, we have (siht) in 
all cases.

The main difference, from a user POV, is that in Arabic you have to press ')' 
for an opening bracket (to get ')' in the LyX window), while in Hebrew you 
have to press '('. This has been the case since support for these languages 
was introduced. I find this also irritating, but maybe these are simply 
different input conventions, logical versus visual (I have added a FIXME that 
requests clarification).

As far as pating is concerned, your should always get (siht) (in the LyX 
window) when you paste (siht). I have not tested this, but the patch also does 
not change this.

 I would prefer if the LyX input were (siht) for both, Hebrew and
 Arabic, regardless of the language package.

Me, too. But then, I'm neither a Hebrew nor an Arabic writer.

 The patch changes the output, i.e. if someone uses the input convention
 used in other Unicode editors and also in Arabic, the output will be wrong
 with LyX.

I don't think this is true.

 In this sense, it changes which input is required to get the correct output:
 
 * You will get the correct output with polyglossia for documents intended
 for Hebrew (babel).
 
 * You will get the wrong output with polyglossia for existing documents that
 used to work with Hebrew (polyglossia).
 
 * You will get the wrong output with polyglossia for text inserted from
   OpenOffice or similar sources.

Can you provide an example?

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-24, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 If I understand right, 

   babel converts the input )siht ekil( to (like this) 

 while

   xelatex+polyglossia converts (siht ekil) to (like this).

 Yes [for Hebrew, for that matter. In Arabic, the case is different. This is 
 why we have )siht( in the LyX source for Hebrew and (siht) for Arabic.]

I see, so we actually have

  (siht)   for Arabic (babel  polyglossia) and Hebrew (polyglossia)
   as well as for Arabic and Hebrew in OpenOffice etc.
  )siht(   for Hebrew (babel)

I would prefer if the LyX input were (siht) for both, Hebrew and
Arabic, regardless of the language package.

 IMO, this is a polyglossia feature. It may be regarded as a regression, if
 we fix it to behave like babel:

 However, the applied patch seems to do exactly this. Whether it is a
 fix or a regression depends on the use case.

  + documents written for babel also work with polyglossia,
  - text pasted from other applications now fails with both, babel and
polyglossia.

 Please correct me if I am wrong. 

 The patch does not touch the input (neither the input method nor the 
 representation in the LyX source and window), we just adapt the output if we 
 output to LaTeX with polyglossia. So I do not think anything will change 
 (except the output with polyglossia will be correct).

The patch changes the output, i.e. if someone uses the input convention
used in other Unicode editors and also in Arabic, the output will be wrong
with LyX. 

In this sense, it changes which input is required to get the correct output:

* You will get the correct output with polyglossia for documents intended for
  Hebrew (babel).
  
* You will get the wrong output with polyglossia for existing documents that
  used to work with Hebrew (polyglossia).

* You will get the wrong output with polyglossia for text inserted from
  OpenOffice or similar sources.  

It fixes one problem but creates two others, this is why I consider this
a regression.

A possible fix would be to toggle the parantheses whenever the document
settings change between use of babel and polyglossia or a function that
does so on user request. Also, the different input conventions and the
reasoning behind them should be documented.

Günter

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
 I see, so we actually have
 
   (siht)   for Arabic (babel  polyglossia) and Hebrew (polyglossia)
   
as well as for Arabic and Hebrew in OpenOffice etc.
   
   )siht(   for Hebrew (babel)

Yes. In the LyX source file, that is. In the LyX workarea, we have (siht) in 
all cases.

The main difference, from a user POV, is that in Arabic you have to press ')' 
for an opening bracket (to get ')' in the LyX window), while in Hebrew you 
have to press '('. This has been the case since support for these languages 
was introduced. I find this also irritating, but maybe these are simply 
different input conventions, logical versus visual (I have added a FIXME that 
requests clarification).

As far as pating is concerned, your should always get (siht) (in the LyX 
window) when you paste (siht). I have not tested this, but the patch also does 
not change this.

 I would prefer if the LyX input were (siht) for both, Hebrew and
 Arabic, regardless of the language package.

Me, too. But then, I'm neither a Hebrew nor an Arabic writer.

 The patch changes the output, i.e. if someone uses the input convention
 used in other Unicode editors and also in Arabic, the output will be wrong
 with LyX.

I don't think this is true.

 In this sense, it changes which input is required to get the correct output:
 
 * You will get the correct output with polyglossia for documents intended
 for Hebrew (babel).
 
 * You will get the wrong output with polyglossia for existing documents that
 used to work with Hebrew (polyglossia).
 
 * You will get the wrong output with polyglossia for text inserted from
   OpenOffice or similar sources.

Can you provide an example?

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-24, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> If I understand right, 

>>   babel converts the input ")siht ekil(" to "(like this)" 

>> while

>>   xelatex+polyglossia converts "(siht ekil)" to "(like this)".

> Yes [for Hebrew, for that matter. In Arabic, the case is different. This is 
> why we have )siht( in the LyX source for Hebrew and (siht) for Arabic.]

I see, so we actually have

  (siht)   for Arabic (babel & polyglossia) and Hebrew (polyglossia)
   as well as for Arabic and Hebrew in OpenOffice etc.
  )siht(   for Hebrew (babel)

I would prefer if the LyX input were "(siht)" for both, Hebrew and
Arabic, regardless of the language package.

>> IMO, this is a polyglossia feature. It may be regarded as a regression, if
>> we "fix" it to behave like babel:

>> However, the applied patch seems to do exactly this. Whether it is a
>> "fix" or a "regression" depends on the use case.

>>  + documents written for babel also work with polyglossia,
>>  - text pasted from other applications now fails with both, babel and
>>polyglossia.

>> Please correct me if I am wrong. 

> The patch does not touch the input (neither the input method nor the 
> representation in the LyX source and window), we just adapt the output if we 
> output to LaTeX with polyglossia. So I do not think anything will change 
> (except the output with polyglossia will be correct).

The patch changes the output, i.e. if someone uses the input convention
used in other Unicode editors and also in Arabic, the output will be wrong
with LyX. 

In this sense, it changes which input is required to get the correct output:

* You will get the correct output with polyglossia for documents intended for
  Hebrew (babel).
  
* You will get the wrong output with polyglossia for existing documents that
  used to work with Hebrew (polyglossia).

* You will get the wrong output with polyglossia for text inserted from
  OpenOffice or similar sources.  

It fixes one problem but creates two others, this is why I consider this
a regression.

A possible fix would be to toggle the parantheses whenever the document
settings change between use of "babel" and "polyglossia" or a function that
does so on user request. Also, the different input conventions and the
reasoning behind them should be documented.

Günter

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
> I see, so we actually have
> 
>   (siht)   for Arabic (babel & polyglossia) and Hebrew (polyglossia)
>   
>as well as for Arabic and Hebrew in OpenOffice etc.
>   
>   )siht(   for Hebrew (babel)

Yes. In the LyX source file, that is. In the LyX workarea, we have (siht) in 
all cases.

The main difference, from a user POV, is that in Arabic you have to press ')' 
for an opening bracket (to get ')' in the LyX window), while in Hebrew you 
have to press '('. This has been the case since support for these languages 
was introduced. I find this also irritating, but maybe these are simply 
different input conventions, logical versus visual (I have added a FIXME that 
requests clarification).

As far as pating is concerned, your should always get (siht) (in the LyX 
window) when you paste (siht). I have not tested this, but the patch also does 
not change this.

> I would prefer if the LyX input were "(siht)" for both, Hebrew and
> Arabic, regardless of the language package.

Me, too. But then, I'm neither a Hebrew nor an Arabic writer.

> The patch changes the output, i.e. if someone uses the input convention
> used in other Unicode editors and also in Arabic, the output will be wrong
> with LyX.

I don't think this is true.

> In this sense, it changes which input is required to get the correct output:
> 
> * You will get the correct output with polyglossia for documents intended
> for Hebrew (babel).
> 
> * You will get the wrong output with polyglossia for existing documents that
> used to work with Hebrew (polyglossia).
> 
> * You will get the wrong output with polyglossia for text inserted from
>   OpenOffice or similar sources.

Can you provide an example?

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
 If I understand right, 
 
   babel converts the input )siht ekil( to (like this) 
   
 while
 
   xelatex+polyglossia converts (siht ekil) to (like this).

Yes [for Hebrew, for that matter. In Arabic, the case is different. This is 
why we have )siht( in the LyX source for Hebrew and (siht) for Arabic.]

 IMO, this is a polyglossia feature. It may be regarded as a regression, if
 we fix it to behave like babel:
 
 However, the applied patch seems to do exactly this. Whether it is a
 fix or a regression depends on the use case.
 
  + documents written for babel also work with polyglossia,
  - text pasted from other applications now fails with both, babel and
polyglossia.
 
 
 Please correct me if I am wrong. 

The patch does not touch the input (neither the input method nor the 
representation in the LyX source and window), we just adapt the output if we 
output to LaTeX with polyglossia. So I do not think anything will change 
(except the output with polyglossia will be correct).

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
 If I understand right, 
 
   babel converts the input )siht ekil( to (like this) 
   
 while
 
   xelatex+polyglossia converts (siht ekil) to (like this).

Yes [for Hebrew, for that matter. In Arabic, the case is different. This is 
why we have )siht( in the LyX source for Hebrew and (siht) for Arabic.]

 IMO, this is a polyglossia feature. It may be regarded as a regression, if
 we fix it to behave like babel:
 
 However, the applied patch seems to do exactly this. Whether it is a
 fix or a regression depends on the use case.
 
  + documents written for babel also work with polyglossia,
  - text pasted from other applications now fails with both, babel and
polyglossia.
 
 
 Please correct me if I am wrong. 

The patch does not touch the input (neither the input method nor the 
representation in the LyX source and window), we just adapt the output if we 
output to LaTeX with polyglossia. So I do not think anything will change 
(except the output with polyglossia will be correct).

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
> If I understand right, 
> 
>   babel converts the input ")siht ekil(" to "(like this)" 
>   
> while
> 
>   xelatex+polyglossia converts "(siht ekil)" to "(like this)".

Yes [for Hebrew, for that matter. In Arabic, the case is different. This is 
why we have )siht( in the LyX source for Hebrew and (siht) for Arabic.]

> IMO, this is a polyglossia feature. It may be regarded as a regression, if
> we "fix" it to behave like babel:
> 
> However, the applied patch seems to do exactly this. Whether it is a
> "fix" or a "regression" depends on the use case.
> 
>  + documents written for babel also work with polyglossia,
>  - text pasted from other applications now fails with both, babel and
>polyglossia.
> 
> 
> Please correct me if I am wrong. 

The patch does not touch the input (neither the input method nor the 
representation in the LyX source and window), we just adapt the output if we 
output to LaTeX with polyglossia. So I do not think anything will change 
(except the output with polyglossia will be correct).

Jürgen

Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

Hello to you all,

Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
myself, and it works grate for Hebrew.
For more information, see
http://www.lyx.org/trac/ticket/8251


But as Arabic and Farsi are also Right-To-Left languages, I assume this
correction also effect these languages. From 1st glance, it seems that
Arabic also works good now, but I have no real experience in writing
Arabic\Farsi in LyX. If you do use LyX in Arabic or Farsi, I will be happy
if you'll help checking it.

System Req:
- New version of LaTeX, like texLive 2011 (texLive 2009, as in Ubuntu, have
an old version of Bidi and polyglassia packages, so you'll have to install
them manually,  http://ctan.org/tex-archive/macros/xetex/latex/polyglossia,
http://www.ctan.org/tex-archive/macros/latex/contrib/bidi/ )
 - LyX, updated GIT version with the patch rtl2.diff from
http://www.lyx.org/trac/ticket/8251
 - Unicode-enabled TTF arabic\farci font. I used Debian package
fonts-sil-scheherazade for arabic font.

What to do:
- In an old (2.0x) LyX version, write an arabic document.
- Document-Preferences-Fonts.  mark 'use non-Tex fonts' and choose a
proper arabic\farsi font from the available combos.
- Write a document that contains many braces, ( ) ,  , {} , []  [in
Arabic\Farsi and in English, not in math)
- Compile the document using XeTex  (View-View [other formats] - PDF
(XeTeX)
- Is the document compiled properly? is all the braces are as expected?

Do the same thing with the patched GIT version:
- Is the document compiled properly? is all the braces are as expected?

If, in the patched version not everything works grate, please attached the
original LyX file, the output PDF, and if possible, also the XeTeX output.


Thanks,
Ronen.

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-23, Ronen Abravanel wrote:

 Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
 document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
 myself, and it works grate for Hebrew.
 For more information, see
 http://www.lyx.org/trac/ticket/8251

 What to do:
 - In an old (2.0x) LyX version, write an arabic document.
 - Document-Preferences-Fonts.  mark 'use non-Tex fonts' and choose a
 proper arabic\farsi font from the available combos.
 - Write a document that contains many braces, ( ) ,  , {} , []  [in
 Arabic\Farsi and in English, not in math)
 - Compile the document using XeTex  (View-View [other formats] - PDF
 (XeTeX)
 - Is the document compiled properly? is all the braces are as expected?

 Do the same thing with the patched GIT version:
 - Is the document compiled properly? is all the braces are as expected?

Please also check, if you prefer to input the braces in the way old LyX
documents do it, )siht ekil(, or if you prefer to input the braces in
the Unicode way (siht ekil). The latter should come out right without
the patch but may no longer with it!

 If, in the patched version not everything works grate, please attached the
 original LyX file, the output PDF, and if possible, also the XeTeX output.

Günter

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
 Please also check, if you prefer to input the braces in the way old LyX
 documents do it, )siht ekil(, or if you prefer to input the braces in
 the Unicode way (siht ekil). The latter should come out right without
 the patch but may no longer with it!

This has not been changed (it would be a file format change).

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Ronen Abravanel wrote:
 Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
 document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
 myself, and it works grate for Hebrew.
 For more information, see
 http://www.lyx.org/trac/ticket/8251
 
 
 But as Arabic and Farsi are also Right-To-Left languages, I assume this
 correction also effect these languages. From 1st glance, it seems that
 Arabic also works good now, but I have no real experience in writing
 Arabic\Farsi in LyX. If you do use LyX in Arabic or Farsi, I will be happy
 if you'll help checking it.
 
 System Req:
[...]
  - LyX, updated GIT version with the patch rtl2.diff from
 http://www.lyx.org/trac/ticket/8251

Since the patch has meanwhile been applied, you do not need the mentioned 
patch. Just pull the most recent master.

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-23, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 Please also check, if you prefer to input the braces in the way old LyX
 documents do it, )siht ekil(, or if you prefer to input the braces in
 the Unicode way (siht ekil). The latter should come out right without
 the patch but may no longer with it!

 This has not been changed (it would be a file format change).

If I understand right, 

  babel converts the input )siht ekil( to (like this) 
  
while

  xelatex+polyglossia converts (siht ekil) to (like this).
  
IMO, this is a polyglossia feature. It may be regarded as a regression, if
we fix it to behave like babel:

However, the applied patch seems to do exactly this. Whether it is a
fix or a regression depends on the use case.

 + documents written for babel also work with polyglossia,
 - text pasted from other applications now fails with both, babel and
   polyglossia.


Please correct me if I am wrong. 

Günter

Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

Hello to you all,

Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
myself, and it works grate for Hebrew.
For more information, see
http://www.lyx.org/trac/ticket/8251


But as Arabic and Farsi are also Right-To-Left languages, I assume this
correction also effect these languages. From 1st glance, it seems that
Arabic also works good now, but I have no real experience in writing
Arabic\Farsi in LyX. If you do use LyX in Arabic or Farsi, I will be happy
if you'll help checking it.

System Req:
- New version of LaTeX, like texLive 2011 (texLive 2009, as in Ubuntu, have
an old version of Bidi and polyglassia packages, so you'll have to install
them manually,  http://ctan.org/tex-archive/macros/xetex/latex/polyglossia,
http://www.ctan.org/tex-archive/macros/latex/contrib/bidi/ )
 - LyX, updated GIT version with the patch rtl2.diff from
http://www.lyx.org/trac/ticket/8251
 - Unicode-enabled TTF arabic\farci font. I used Debian package
fonts-sil-scheherazade for arabic font.

What to do:
- In an old (2.0x) LyX version, write an arabic document.
- Document-Preferences-Fonts.  mark 'use non-Tex fonts' and choose a
proper arabic\farsi font from the available combos.
- Write a document that contains many braces, ( ) ,  , {} , []  [in
Arabic\Farsi and in English, not in math)
- Compile the document using XeTex  (View-View [other formats] - PDF
(XeTeX)
- Is the document compiled properly? is all the braces are as expected?

Do the same thing with the patched GIT version:
- Is the document compiled properly? is all the braces are as expected?

If, in the patched version not everything works grate, please attached the
original LyX file, the output PDF, and if possible, also the XeTeX output.


Thanks,
Ronen.

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-23, Ronen Abravanel wrote:

 Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
 document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
 myself, and it works grate for Hebrew.
 For more information, see
 http://www.lyx.org/trac/ticket/8251

 What to do:
 - In an old (2.0x) LyX version, write an arabic document.
 - Document-Preferences-Fonts.  mark 'use non-Tex fonts' and choose a
 proper arabic\farsi font from the available combos.
 - Write a document that contains many braces, ( ) ,  , {} , []  [in
 Arabic\Farsi and in English, not in math)
 - Compile the document using XeTex  (View-View [other formats] - PDF
 (XeTeX)
 - Is the document compiled properly? is all the braces are as expected?

 Do the same thing with the patched GIT version:
 - Is the document compiled properly? is all the braces are as expected?

Please also check, if you prefer to input the braces in the way old LyX
documents do it, )siht ekil(, or if you prefer to input the braces in
the Unicode way (siht ekil). The latter should come out right without
the patch but may no longer with it!

 If, in the patched version not everything works grate, please attached the
 original LyX file, the output PDF, and if possible, also the XeTeX output.

Günter

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
 Please also check, if you prefer to input the braces in the way old LyX
 documents do it, )siht ekil(, or if you prefer to input the braces in
 the Unicode way (siht ekil). The latter should come out right without
 the patch but may no longer with it!

This has not been changed (it would be a file format change).

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Ronen Abravanel wrote:
 Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
 document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
 myself, and it works grate for Hebrew.
 For more information, see
 http://www.lyx.org/trac/ticket/8251
 
 
 But as Arabic and Farsi are also Right-To-Left languages, I assume this
 correction also effect these languages. From 1st glance, it seems that
 Arabic also works good now, but I have no real experience in writing
 Arabic\Farsi in LyX. If you do use LyX in Arabic or Farsi, I will be happy
 if you'll help checking it.
 
 System Req:
[...]
  - LyX, updated GIT version with the patch rtl2.diff from
 http://www.lyx.org/trac/ticket/8251

Since the patch has meanwhile been applied, you do not need the mentioned 
patch. Just pull the most recent master.

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-23, Jürgen Spitzmüller wrote:
 Guenter Milde wrote:
 Please also check, if you prefer to input the braces in the way old LyX
 documents do it, )siht ekil(, or if you prefer to input the braces in
 the Unicode way (siht ekil). The latter should come out right without
 the patch but may no longer with it!

 This has not been changed (it would be a file format change).

If I understand right, 

  babel converts the input )siht ekil( to (like this) 
  
while

  xelatex+polyglossia converts (siht ekil) to (like this).
  
IMO, this is a polyglossia feature. It may be regarded as a regression, if
we fix it to behave like babel:

However, the applied patch seems to do exactly this. Whether it is a
fix or a regression depends on the use case.

 + documents written for babel also work with polyglossia,
 - text pasted from other applications now fails with both, babel and
   polyglossia.


Please correct me if I am wrong. 

Günter

Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

Hello to you all,

Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
myself, and it works grate for Hebrew.
For more information, see
http://www.lyx.org/trac/ticket/8251


But as Arabic and Farsi are also Right-To-Left languages, I assume this
correction also effect these languages. From 1st glance, it seems that
Arabic also works good now, but I have no real experience in writing
Arabic\Farsi in LyX. If you do use LyX in Arabic or Farsi, I will be happy
if you'll help checking it.

System Req:
- New version of LaTeX, like texLive 2011 (texLive 2009, as in Ubuntu, have
an old version of Bidi and polyglassia packages, so you'll have to install
them manually,  http://ctan.org/tex-archive/macros/xetex/latex/polyglossia,
http://www.ctan.org/tex-archive/macros/latex/contrib/bidi/ )
 - LyX, updated GIT version with the patch rtl2.diff from
http://www.lyx.org/trac/ticket/8251
 - Unicode-enabled TTF arabic\farci font. I used Debian package
fonts-sil-scheherazade for arabic font.

What to do:
- In an old (2.0x) LyX version, write an arabic document.
- Document->Preferences->Fonts.  mark 'use non-Tex fonts' and choose a
proper arabic\farsi font from the available combos.
- Write a document that contains many braces, ( ) , <> , {} , []  [in
Arabic\Farsi and in English, not in math)
- Compile the document using XeTex  (View->View [other formats] -> PDF
(XeTeX)
- Is the document compiled properly? is all the braces are as expected?

Do the same thing with the patched GIT version:
- Is the document compiled properly? is all the braces are as expected?

If, in the patched version not everything works grate, please attached the
original LyX file, the output PDF, and if possible, also the XeTeX output.


Thanks,
Ronen.

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-23, Ronen Abravanel wrote:

> Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
> document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
> myself, and it works grate for Hebrew.
> For more information, see
> http://www.lyx.org/trac/ticket/8251

> What to do:
> - In an old (2.0x) LyX version, write an arabic document.
> - Document->Preferences->Fonts.  mark 'use non-Tex fonts' and choose a
> proper arabic\farsi font from the available combos.
> - Write a document that contains many braces, ( ) , <> , {} , []  [in
> Arabic\Farsi and in English, not in math)
> - Compile the document using XeTex  (View->View [other formats] -> PDF
> (XeTeX)
> - Is the document compiled properly? is all the braces are as expected?

> Do the same thing with the patched GIT version:
> - Is the document compiled properly? is all the braces are as expected?

Please also check, if you prefer to input the braces in the way old LyX
documents do it, ")siht ekil(", or if you prefer to input the braces in
the "Unicode" way "(siht ekil)". The latter should come out right without
the patch but may no longer with it!

> If, in the patched version not everything works grate, please attached the
> original LyX file, the output PDF, and if possible, also the XeTeX output.

Günter

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Guenter Milde wrote:
> Please also check, if you prefer to input the braces in the way old LyX
> documents do it, ")siht ekil(", or if you prefer to input the braces in
> the "Unicode" way "(siht ekil)". The latter should come out right without
> the patch but may no longer with it!

This has not been changed (it would be a file format change).

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Jürgen Spitzmüller]

Ronen Abravanel wrote:
> Recently, I bumped into a 'bug' that effects the export of Hebrew LyX
> document into XeTeX documents. The bug was fixed by Jürgen Spitzmüller and
> myself, and it works grate for Hebrew.
> For more information, see
> http://www.lyx.org/trac/ticket/8251
> 
> 
> But as Arabic and Farsi are also Right-To-Left languages, I assume this
> correction also effect these languages. From 1st glance, it seems that
> Arabic also works good now, but I have no real experience in writing
> Arabic\Farsi in LyX. If you do use LyX in Arabic or Farsi, I will be happy
> if you'll help checking it.
> 
> System Req:
[...]
>  - LyX, updated GIT version with the patch rtl2.diff from
> http://www.lyx.org/trac/ticket/8251

Since the patch has meanwhile been applied, you do not need the mentioned 
patch. Just pull the most recent master.

Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Guenter Milde]

On 2012-07-23, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> Please also check, if you prefer to input the braces in the way old LyX
>> documents do it, ")siht ekil(", or if you prefer to input the braces in
>> the "Unicode" way "(siht ekil)". The latter should come out right without
>> the patch but may no longer with it!

> This has not been changed (it would be a file format change).

If I understand right, 

  babel converts the input ")siht ekil(" to "(like this)" 
  
while

  xelatex+polyglossia converts "(siht ekil)" to "(like this)".
  
IMO, this is a polyglossia feature. It may be regarded as a regression, if
we "fix" it to behave like babel:

However, the applied patch seems to do exactly this. Whether it is a
"fix" or a "regression" depends on the use case.

 + documents written for babel also work with polyglossia,
 - text pasted from other applications now fails with both, babel and
   polyglossia.


Please correct me if I am wrong. 

Günter