2) The current Arabic keymap lib/kbd/arabic.kmap doesn't provide the
points, as far as I can see. Is this because it follows a standard
layout, but the standard doesn't provide them? Is there a standard
layout which we could follow which would allow us to add these?
Yes definitely there
2) The current Arabic keymap lib/kbd/arabic.kmap doesn't provide the
points, as far as I can see. Is this because it follows a standard
layout, but the standard doesn't provide them? Is there a standard
layout which we could follow which would allow us to add these?
Yes definitely there
Mostafa Vahedi wrote:
b) The current code in the method Paragraph::transformChar has
a bug,
when the prev_char is a COMPOSE character (such as FATHA) and the
previous BASE character is a SPECIAL character (such as ALEF). In
this case the current character (such as BAA)
Abdelrazak Younes wrote:
Mostafa Vahedi wrote:
b) The current code in the method Paragraph::transformChar has
a bug,
when the prev_char is a COMPOSE character (such as FATHA) and the
previous BASE character is a SPECIAL character (such as ALEF). In
this case the current
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Mostafa Vahedi wrote:
b) The current code in the method Paragraph::transformChar has
a bug,
when the prev_char is a COMPOSE character (such as FATHA) and the
previous BASE character is a SPECIAL character (such as ALEF). In
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Here is the patch against latest svn. Dov, could you confirm that it
works fine?
Abdel.
Hi!
Yes, it works, and looks good --- it should go in, as far as I'm
concerned. Good work, Mostafa! :)
Congratulation Mostafa, you are now part of the
Congratulation Mostafa, you are now part of the happy LyX family! :-)
Thanks.
Please send a mail to the list stating that you agree to license your
contribution to the LyX project with GPL version 2 or later.
I agree to license my contribution to the LyX project with GPL version 2 or
1) Can anyone recommend a screenfont (Linux/X11) which has glyphs for
the points (FATHA, etc.) --- the font I'm currently using just shows a
box...
Install msttcorefonts of microsoft fonts.
2) The current Arabic keymap lib/kbd/arabic.kmap doesn't provide the
points, as far as I can see.
Mostafa wrote:
Suppose that we have a text with a mixture of English, Arabic, and Farsi
languages. Therefore consider a paragraph that its main language is English and
it contains both Arabic and Farsi words. The current part of the source that
converts LyX to LaTeX uses the command \R{}
Mostafa Vahedi wrote:
Congratulation Mostafa, you are now part of the happy LyX family! :-)
Thanks.
Please send a mail to the list stating that you agree to license your
contribution to the LyX project with GPL version 2 or later.
I agree to license my contribution to the LyX project
Mostafa Vahedi wrote:
> b) The current code in the method "Paragraph::transformChar" has
a bug,
> when the prev_char is a COMPOSE character (such as FATHA) and the
previous BASE character is a SPECIAL character (such as ALEF). In
this case the current character (such as
Abdelrazak Younes wrote:
Mostafa Vahedi wrote:
> b) The current code in the method "Paragraph::transformChar" has
a bug,
> when the prev_char is a COMPOSE character (such as FATHA) and the
previous BASE character is a SPECIAL character (such as ALEF). In
this case the
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Mostafa Vahedi wrote:
> b) The current code in the method "Paragraph::transformChar" has
a bug,
> when the prev_char is a COMPOSE character (such as FATHA) and the
previous BASE character is a SPECIAL character (such as ALEF).
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Here is the patch against latest svn. Dov, could you confirm that it
works fine?
Abdel.
Hi!
Yes, it works, and looks good --- it should go in, as far as I'm
concerned. Good work, Mostafa! :)
Congratulation Mostafa, you are now part of the
Congratulation Mostafa, you are now part of the happy LyX family! :-)
Thanks.
Please send a mail to the list stating that you agree to license your
contribution to the LyX project with GPL version 2 or later.
I agree to license my contribution to the LyX project with GPL version 2 or
1) Can anyone recommend a screenfont (Linux/X11) which has glyphs for
the points (FATHA, etc.) --- the font I'm currently using just shows a
box...
Install "msttcorefonts" of microsoft fonts.
2) The current Arabic keymap lib/kbd/arabic.kmap doesn't provide the
points, as far as I can
Mostafa wrote:
Suppose that we have a text with a mixture of English, Arabic, and Farsi
languages. Therefore consider a paragraph that its main language is English and
it contains both Arabic and Farsi words. The current part of the source that
converts LyX to LaTeX uses the command "\R{}"
Mostafa Vahedi wrote:
Congratulation Mostafa, you are now part of the happy LyX family! :-)
Thanks.
Please send a mail to the list stating that you agree to license your
contribution to the LyX project with GPL version 2 or later.
I agree to license my contribution to the LyX project
Hi!
I'm sorry -- I threw this whole thread off in a wrong direction, and it
turns out that I was mistaken: the current status of Arabic support in
the frontend, as far as I can see, is perfectly all right: the shaping
takes place correctly, and positioning of the cursor is correct. What
Mostafa Vahedi wrote:
a) Currently the characters are painted in two ways in the current source:
1) the source itself handles the shaping
2) Qt handles the shaping
It seems that it is possible to let Qt do a part (not all) of the first item
too. I am not sure yet! I will investigate the
a) Currently the characters are painted in two ways in the current source:
1) the source itself handles the shaping
2) Qt handles the shaping
It seems that it is possible to let Qt do a part (not all) of the first item
too. I am not sure yet! I will investigate the suggestion more.
I
Hi!
I'm sorry -- I threw this whole thread off in a wrong direction, and it
turns out that I was mistaken: the current status of Arabic support in
the frontend, as far as I can see, is perfectly all right: the shaping
takes place correctly, and positioning of the cursor is correct. What
Mostafa Vahedi wrote:
a) Currently the characters are painted in two ways in the current source:
1) the source itself handles the shaping
2) Qt handles the shaping
It seems that it is possible to let Qt do a part (not all) of the first item
too. I am not sure yet! I will investigate the
> a) Currently the characters are painted in two ways in the current source:
> 1) the source itself handles the shaping
> 2) Qt handles the shaping
> It seems that it is possible to let Qt do a part (not all) of the first item
> too. I am not sure yet! I will investigate the suggestion more.
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Right now the transformChar() is called only before painting, which is
wrong because cursor positioning happens at metrics calculation time.
So to solve this we have two solution:
1) we move the RTL logic out of rowpainter.C and use
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Right now the transformChar() is called only before painting, which is
wrong because cursor positioning happens at metrics calculation time.
So to solve this we have two solution:
1) we move the RTL logic out of rowpainter.C and use
a) Currently the characters are painted in two ways in the current source:
1) the source itself handles the shaping
2) Qt handles the shaping
It seems that it is possible to let Qt do a part (not all) of the first item
too. I am not sure yet! I will investigate the suggestion more.
b) The
Mostafa Vahedi wrote:
a) Currently the characters are painted in two ways in the current
source:
1) the source itself handles the shaping
2) Qt handles the shaping
Yes.
It seems that it is possible to let Qt do a part (not all) of the
first item too. I am not sure yet! I will investigate
Hi!
It's nice to see some new people getting involved with the Bidi development!
Mostafa Vahedi wrote:
a) Currently the characters are painted in two ways in the current source:
1) the source itself handles the shaping
2) Qt handles the shaping
It seems that it is possible to let Qt do a
Dov Feldstern wrote:
The main problem I see right now with Arabic is that the widths of the
letters are not calculated correctly. This means that letters may not
totally connect with their neighbors, because their glyph doesn't
totally cover the space given to them. (Are you seeing the same
Abdelrazak Younes wrote:
Dov Feldstern wrote:
The main problem I see right now with Arabic is that the widths of the
letters are not calculated correctly. This means that letters may not
totally connect with their neighbors, because their glyph doesn't
totally cover the space given to them.
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
The main problem I see right now with Arabic is that the widths of
the letters are not calculated correctly. This means that letters may
not totally connect with their neighbors, because their glyph doesn't
totally cover the
Abdelrazak Younes wrote:
Right now the transformChar() is called only before painting, which is
wrong because cursor positioning happens at metrics calculation time. So
to solve this we have two solution:
1) we move the RTL logic out of rowpainter.C and use transformChar() in
Abdelrazak Younes wrote:
Right now the transformChar() is called only before painting, which is
wrong because cursor positioning happens at metrics calculation time. So
to solve this we have two solution:
1) we move the RTL logic out of rowpainter.C and use transformChar() in
a) Currently the characters are painted in two ways in the current source:
1) the source itself handles the shaping
2) Qt handles the shaping
It seems that it is possible to let Qt do a part (not all) of the first item
too. I am not sure yet! I will investigate the suggestion more.
b) The
Mostafa Vahedi wrote:
a) Currently the characters are painted in two ways in the current
source:
>
1) the source itself handles the shaping
2) Qt handles the shaping
Yes.
It seems that it is possible to let Qt do a part (not all) of the
first item too. I am not sure yet! I will
Hi!
It's nice to see some new people getting involved with the Bidi development!
Mostafa Vahedi wrote:
a) Currently the characters are painted in two ways in the current source:
1) the source itself handles the shaping
2) Qt handles the shaping
It seems that it is possible to let Qt do a
Dov Feldstern wrote:
The main problem I see right now with Arabic is that the widths of the
letters are not calculated correctly. This means that letters may not
totally connect with their neighbors, because their glyph doesn't
totally cover the space given to them. (Are you seeing the same
Abdelrazak Younes wrote:
Dov Feldstern wrote:
The main problem I see right now with Arabic is that the widths of the
letters are not calculated correctly. This means that letters may not
totally connect with their neighbors, because their glyph doesn't
totally cover the space given to them.
Dov Feldstern wrote:
Abdelrazak Younes wrote:
Dov Feldstern wrote:
The main problem I see right now with Arabic is that the widths of
the letters are not calculated correctly. This means that letters may
not totally connect with their neighbors, because their glyph doesn't
totally cover the
Abdelrazak Younes wrote:
Right now the transformChar() is called only before painting, which is
wrong because cursor positioning happens at metrics calculation time. So
to solve this we have two solution:
1) we move the RTL logic out of rowpainter.C and use transformChar() in
Abdelrazak Younes wrote:
Right now the transformChar() is called only before painting, which is
wrong because cursor positioning happens at metrics calculation time. So
to solve this we have two solution:
1) we move the RTL logic out of rowpainter.C and use transformChar() in
I don't know whether it is a good time to think about improving Arabic-like
language support (such as Farsi). If the answer is yes then:
First, I would like to contribute to the project working in this area.
Second, there are a number of languages similar to Arabic such as Farsi and
Kurdish
Mostafa Vahedi wrote:
I don't know whether it is a good time to think about improving
Arabic-like language support (such as Farsi). If the answer is yes
then:
Yes, definitely. Now is the right time.
First, I would like to contribute to the project working in this
area.
Welcome!
Second
I don't know whether it is a good time to think about improving Arabic-like
language support (such as Farsi). If the answer is yes then:
First, I would like to contribute to the project working in this area.
Second, there are a number of languages similar to Arabic such as Farsi and
Kurdish
Mostafa Vahedi wrote:
I don't know whether it is a good time to think about improving
Arabic-like language support (such as Farsi). If the answer is yes
then:
Yes, definitely. Now is the right time.
First, I would like to contribute to the project working in this
area.
Welcome!
Second
46 matches
Mail list logo
