Farsi Problems in LyX 1.6.7
Hi,
I've started translating LyX introduction (intro.lyx) into Persian, and I'm
using builtin Farsi support that uses Arabi package. There are some bugs in
Farsi support that I've encountered, and I try to list those that are most
important. I'm using LyX 1.6.7 on win32.
Some of them are bugs of Arabi pacakge, and some of them are related to LyX.
I try to separate them:
*LyX bugs:*
1. Wrong Shaping: '«' and '»' are shown in wrong manner (reverse), but they
appear correctly in the output. Please see the attached picture.
2. Numbers that are cut/pasted into LyX, does not enclose in \beginL and
\endL. The output will contain digits that are shown in reverse order
right: {\beginL 1389 \endL}
wrong: 1389
Note that there is no problem when you write numbers inside LyX. This may
have workarounds in Arabi.
3. When I write English inside Farsi text, \textLR is not inserted
automatically, English text is shown in reverse order by LyX, and the output
will not contain that English text. according to this (in Farsi:
http://farsilatex.blogfa.com/post-92.aspx ), Mr. Vahedi has created a key
binding file, fa_cua.bind, that is no longer available from the specified
URL.
*Arabi bugs:*
1. Some characters causes wrong shaping of characters, according to their
position. For example, '«' and '»' cause problems, because they join to the
character that is right after them. Please see the attached picture.
2. I can't use hyperref package between Farsi Text. In this situation, DVI
can be generated without problem, but PDF generation stops with this error:
*pdfTeX error (ext4): pdf_link_stack empty, \pdfendlink used without
\pdfstart*
if I use \textLR, I will get this error:
*This can't happen (copying).*
3. Character ۀ causes package inputenc error:
*Package inputenc Error: Unicode char \u8:غ€ not set up for use with LaTeX.*
4. Default paragraph spacing is very tight.
Please tell me if I should file a bug for these problems. I would be happy
if I can help to fix some of them.
As you may be aware, Mr. Vahedi and some other enthusiasts in this area are
working on XePersian that seems to be stable and bug-free. This is an
alternative for Farsi support in LyX, because Arabi has not been updated
since 12/2006. Please see http://www.parsilatex.com/ (content is in Farsi
language). It seems that his e-mail and home-page is changed, so I cc this
e-mail to his new email address, and I hope he will also receive it.
Thanks,
Hossein
attachment: lyx.PNG
intro-fa.lyx
Description: Binary data
MOC Dependencies
With SignalSlotPrivate, in particular, I sometimes get errors of the generated by an older MOC variety, and then I have to manually delete SignalSlotPrivate_moc.cpp. Can this somehow be automated via make? rh
Re: [patch] support for customizable horizontal lines
Uwe Stöhr wrote: when i enabled debuging symbols on, the crash disappeared though. so i can't give more precise backtrace, sorry. Abdel, it didn't crash before you transformed the dialog from CommandInset to InsetWidgets. do you understand why the code in r35299 string width_str = fromqstr(WidthLE-text()); if (width_str[0] == '-') width_str.erase(0,1); must crash sooner or later? (this idiom repeats more times in the code) the sad thing is that as well as the magic constants monster these lines were not in the patch you have asked in the list. what is the point of asking for review, when you commit different things? well, nobody reacted as you hoped. what do you propose now? Give me some time please. no problem, but the message has red bullet in my mailbox and i'm not gonna to forget on it if you hope so :) i will reply to the rest of questions once the crashes are gone. maybe things will improve by then. pavel few other glitches i saw: - no focus in dialog set up initially Abdel? - there should be some implicit value in boxes, which are generally sensible (best would be such values, which would repeat the behaviour of 1.6 version of horizontal line). I don't understand. The default values when inserting a horizontal line are those of the old \lyxline. - if i set big offset by mistake like, like 1 cm it has very strange painting results and interfering randomly with tezt/insetss around. moreover the typeset looks completely different. i guess some geometry stuff is broken. I'm not on my box and thus cannot test, but when committed it worked well - the line drawn on screen looked nearly as in the PDF output. Do you have a LyX testfile for me? regards Uwe
Re: [patch] support for customizable horizontal lines
Am 10.09.2010 20:49, schrieb Pavel Sanda: do you understand why the code in r35299 string width_str = fromqstr(WidthLE-text()); if (width_str[0] == '-') width_str.erase(0,1); must crash sooner or later? No. I check if the string begins with a '-' sign and if so, I remove this character from the string because I want to turn it into a positive one without casting the string to a float and then back to a string. This works well here and doesn't crash. But as you know I'm a miserable programmer and it seems I have overseen something. the sad thing is that as well as the magic constants monster these lines were not in the patch you have asked in the list. what is the point of asking for review, when you commit different things? These were last minute changes. The magic constant was for JMarc to solve this but I'll revert this for now. The other issue was that i noticed that we need positive values for width and height and thought this is uncontroversial. well, nobody reacted as you hoped. what do you propose now? Give me some time please. no problem, but the message has red bullet in my mailbox and i'm not gonna to forget on it if you hope so :) Having buggy code in a release is of course not acceptable. The problem is that I have currently really pressing real life stuff and thus no time to have a look the next 3 days I fear. thanks for taking care and regards Uwe
Re: [patch] support for customizable horizontal lines
Uwe Stöhr wrote: Am 10.09.2010 20:49, schrieb Pavel Sanda: do you understand why the code in r35299 string width_str = fromqstr(WidthLE-text()); if (width_str[0] == '-') width_str.erase(0,1); must crash sooner or later? No. I check if the string begins with a '-' sign and if so, I remove this character from the string because I want to turn it into a positive one without casting the string to a float and then back to a string. This works well here and doesn't crash. But as you know I'm a miserable programmer and it seems I have overseen something. the problem is what happens when width_str is empty. then no width_str[0] exists and accessing it is asking for crash. pavel
Re: [patch] support for customizable horizontal lines
Am Samstag, den 11.09.2010, 00:14 +0200 schrieb Pavel Sanda:
Uwe Stöhr wrote:
Am 10.09.2010 20:49, schrieb Pavel Sanda:
do you understand why the code in r35299
string width_str = fromqstr(WidthLE-text());
if (width_str[0] == '-')
width_str.erase(0,1);
must crash sooner or later?
No. I check if the string begins with a '-' sign and if so, I remove this
character from the string because I want to turn it into a positive one
without casting the string to a float and then back to a string. This works
well here and doesn't crash.
But as you know I'm a miserable programmer and it seems I have overseen
something.
the problem is what happens when width_str is empty. then no width_str[0]
exists and accessing it is asking for crash.
pavel
if (WidthLE-text().startsWith('-')) {
Peter
Farsi Problems in LyX 1.6.7
Hi,
I've started translating LyX introduction (intro.lyx) into Persian, and I'm
using builtin Farsi support that uses Arabi package. There are some bugs in
Farsi support that I've encountered, and I try to list those that are most
important. I'm using LyX 1.6.7 on win32.
Some of them are bugs of Arabi pacakge, and some of them are related to LyX.
I try to separate them:
*LyX bugs:*
1. Wrong Shaping: '«' and '»' are shown in wrong manner (reverse), but they
appear correctly in the output. Please see the attached picture.
2. Numbers that are cut/pasted into LyX, does not enclose in \beginL and
\endL. The output will contain digits that are shown in reverse order
right: {\beginL 1389 \endL}
wrong: 1389
Note that there is no problem when you write numbers inside LyX. This may
have workarounds in Arabi.
3. When I write English inside Farsi text, \textLR is not inserted
automatically, English text is shown in reverse order by LyX, and the output
will not contain that English text. according to this (in Farsi:
http://farsilatex.blogfa.com/post-92.aspx ), Mr. Vahedi has created a key
binding file, fa_cua.bind, that is no longer available from the specified
URL.
*Arabi bugs:*
1. Some characters causes wrong shaping of characters, according to their
position. For example, '«' and '»' cause problems, because they join to the
character that is right after them. Please see the attached picture.
2. I can't use hyperref package between Farsi Text. In this situation, DVI
can be generated without problem, but PDF generation stops with this error:
*pdfTeX error (ext4): pdf_link_stack empty, \pdfendlink used without
\pdfstart*
if I use \textLR, I will get this error:
*This can't happen (copying).*
3. Character "ۀ" causes package inputenc error:
*Package inputenc Error: Unicode char \u8:غ€ not set up for use with LaTeX.*
4. Default paragraph spacing is very tight.
Please tell me if I should file a bug for these problems. I would be happy
if I can help to fix some of them.
As you may be aware, Mr. Vahedi and some other enthusiasts in this area are
working on XePersian that seems to be stable and bug-free. This is an
alternative for Farsi support in LyX, because Arabi has not been updated
since 12/2006. Please see http://www.parsilatex.com/ (content is in Farsi
language). It seems that his e-mail and home-page is changed, so I cc this
e-mail to his new email address, and I hope he will also receive it.
Thanks,
Hossein
<>
intro-fa.lyx
Description: Binary data
MOC Dependencies
With SignalSlotPrivate, in particular, I sometimes get errors of the "generated by an older MOC" variety, and then I have to manually delete SignalSlotPrivate_moc.cpp. Can this somehow be automated via make? rh
Re: [patch] support for customizable horizontal lines
Uwe Stöhr wrote: >> when i enabled debuging symbols on, the crash disappeared though. >> so i can't give more precise backtrace, sorry. > > Abdel, it didn't crash before you transformed the dialog from CommandInset > to InsetWidgets. do you understand why the code in r35299 string width_str = fromqstr(WidthLE->text()); if (width_str[0] == '-') width_str.erase(0,1); must crash sooner or later? (this idiom repeats more times in the code) the sad thing is that as well as the magic constants monster these lines were not in the patch you have asked in the list. what is the point of asking for review, when you commit different things? >> well, nobody reacted as you hoped. what do you propose now? > > Give me some time please. no problem, but the message has red bullet in my mailbox and i'm not gonna to forget on it if you hope so :) i will reply to the rest of questions once the crashes are gone. maybe things will improve by then. pavel >> few other glitches i saw: >> - no focus in dialog set up initially > > Abdel? > >> - there should be some implicit value in boxes, which are generally >> sensible >>(best would be such values, which would repeat the behaviour of 1.6 >>version of horizontal line). > > I don't understand. The default values when inserting a horizontal line are > those of the old \lyxline. > >> - if i set big offset by mistake like, like 1 cm it has very strange >> painting >>results and interfering randomly with tezt/insetss around. moreover the >>typeset looks completely different. i guess some geometry stuff is >> broken. > > I'm not on my box and thus cannot test, but when committed it worked well - > the line drawn on screen looked nearly as in the PDF output. Do you have a > LyX testfile for me? > > regards Uwe
Re: [patch] support for customizable horizontal lines
Am 10.09.2010 20:49, schrieb Pavel Sanda: do you understand why the code in r35299 string width_str = fromqstr(WidthLE->text()); if (width_str[0] == '-') width_str.erase(0,1); must crash sooner or later? No. I check if the string begins with a '-' sign and if so, I remove this character from the string because I want to turn it into a positive one without casting the string to a float and then back to a string. This works well here and doesn't crash. But as you know I'm a miserable programmer and it seems I have overseen something. the sad thing is that as well as the magic constants monster these lines were not in the patch you have asked in the list. what is the point of asking for review, when you commit different things? These were last minute changes. The magic constant was for JMarc to solve this but I'll revert this for now. The other issue was that i noticed that we need positive values for width and height and thought this is uncontroversial. well, nobody reacted as you hoped. what do you propose now? Give me some time please. no problem, but the message has red bullet in my mailbox and i'm not gonna to forget on it if you hope so :) Having buggy code in a release is of course not acceptable. The problem is that I have currently really pressing real life stuff and thus no time to have a look the next 3 days I fear. thanks for taking care and regards Uwe
Re: [patch] support for customizable horizontal lines
Uwe Stöhr wrote: > Am 10.09.2010 20:49, schrieb Pavel Sanda: > >> do you understand why the code in r35299 >> >> string width_str = fromqstr(WidthLE->text()); >> if (width_str[0] == '-') >>width_str.erase(0,1); >> >> must crash sooner or later? > > No. I check if the string begins with a '-' sign and if so, I remove this > character from the string because I want to turn it into a positive one > without casting the string to a float and then back to a string. This works > well here and doesn't crash. > But as you know I'm a miserable programmer and it seems I have overseen > something. the problem is what happens when width_str is empty. then no width_str[0] exists and accessing it is asking for crash. pavel
Re: [patch] support for customizable horizontal lines
Am Samstag, den 11.09.2010, 00:14 +0200 schrieb Pavel Sanda:
> Uwe Stöhr wrote:
> > Am 10.09.2010 20:49, schrieb Pavel Sanda:
> >
> >> do you understand why the code in r35299
> >>
> >> string width_str = fromqstr(WidthLE->text());
> >> if (width_str[0] == '-')
> >>width_str.erase(0,1);
> >>
> >> must crash sooner or later?
> >
> > No. I check if the string begins with a '-' sign and if so, I remove this
> > character from the string because I want to turn it into a positive one
> > without casting the string to a float and then back to a string. This works
> > well here and doesn't crash.
> > But as you know I'm a miserable programmer and it seems I have overseen
> > something.
>
> the problem is what happens when width_str is empty. then no width_str[0]
> exists and accessing it is asking for crash.
>
> pavel
if (WidthLE->text().startsWith('-')) {
Peter
