Re: bidi stuff (Dekel ?)
John Levon [EMAIL PROTECTED] writes: | On Wed, Jul 30, 2003 at 09:39:08PM +0300, Dekel Tsur wrote: | | 1) If we want to use the Unicode bidi algorithm then we should first use | UCS32 for the text. | | This is indeed the plan. FYI: it is UCS4 (almost equal to UTF32) -- Lgb
Re: bidi stuff (Dekel ?)
John Levon <[EMAIL PROTECTED]> writes: | On Wed, Jul 30, 2003 at 09:39:08PM +0300, Dekel Tsur wrote: | | > 1) If we want to use the Unicode bidi algorithm then we should first use | > UCS32 for the text. | | This is indeed the plan. FYI: it is UCS4 (almost equal to UTF32) -- Lgb
Re: bidi stuff (Dekel ?)
On Sat, Jul 19, 2003 at 06:02:27PM +0100, John Levon wrote: I'm a bit confused why we seem to have our own (incomplete) support for bidi stuff. Is there a good reason we're not using fribidi or equivalent ? In particular we seem to have fairly hackish support via things like auto_number instead of properly implementing the unicode bidi algorithm and supporting the implicit LTR/RTL markers. 1) If we want to use the Unicode bidi algorithm then we should first use UCS32 for the text. 2) The Unicode bidi algorithm uses implicit ordering: the language of the text is inferred from the Unicode code of the chars. In LyX, we already mark the language of the text, so it does not make much sense to use that algorithm. Finally, seeing as you're likely to have a pretty good grasp of the needed unicode work, can you give your thoughts on where we should go from here ? encodings.C *seems* to be an incomplete encoding conversion thing for the specific arabic etc. charsets. Why aren't we using libiconv ? Yes, some parts of encodings.C can be done using some external library.
Re: bidi stuff (Dekel ?)
On Wed, Jul 30, 2003 at 09:39:08PM +0300, Dekel Tsur wrote: 1) If we want to use the Unicode bidi algorithm then we should first use UCS32 for the text. This is indeed the plan. 2) The Unicode bidi algorithm uses implicit ordering: the language of the text is inferred from the Unicode code of the chars. In LyX, we already mark the language of the text, so it does not make much sense to use that algorithm. I see. Basically I'm wondering if we can remove code that we have to maintain in favour of code that the fribidi people have to maintain. Yes, some parts of encodings.C can be done using some external library. OK, thanks. What parts cannot ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: bidi stuff (Dekel ?)
On Wed, Jul 30, 2003 at 07:47:58PM +0100, John Levon wrote: I see. Basically I'm wondering if we can remove code that we have to maintain in favour of code that the fribidi people have to maintain. It is rather short, and with external libraries you might have API changes.. Yes, some parts of encodings.C can be done using some external library. OK, thanks. What parts cannot ? Don't know
Re: bidi stuff (Dekel ?)
On Wed, Jul 30, 2003 at 10:43:53PM +0300, Dekel Tsur wrote: It is rather short That's true but it's also : 1) understood only by one person 2) right in the middle of some complicated code regards, john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: bidi stuff (Dekel ?)
On Sat, Jul 19, 2003 at 06:02:27PM +0100, John Levon wrote: > > I'm a bit confused why we seem to have our own (incomplete) support for > bidi stuff. Is there a good reason we're not using fribidi or equivalent ? > > In particular we seem to have fairly hackish support via things like > auto_number instead of properly implementing the unicode bidi algorithm > and supporting the implicit LTR/RTL markers. 1) If we want to use the Unicode bidi algorithm then we should first use UCS32 for the text. 2) The Unicode bidi algorithm uses implicit ordering: the language of the text is inferred from the Unicode code of the chars. In LyX, we already mark the language of the text, so it does not make much sense to use that algorithm. > Finally, seeing as you're likely to have a pretty good grasp of the > needed unicode work, can you give your thoughts on where we should go > from here ? encodings.C *seems* to be an incomplete encoding conversion > thing for the specific arabic etc. charsets. Why aren't we using > libiconv ? Yes, some parts of encodings.C can be done using some external library.
Re: bidi stuff (Dekel ?)
On Wed, Jul 30, 2003 at 09:39:08PM +0300, Dekel Tsur wrote: > 1) If we want to use the Unicode bidi algorithm then we should first use > UCS32 for the text. This is indeed the plan. > 2) The Unicode bidi algorithm uses implicit ordering: the language of the > text is inferred from the Unicode code of the chars. > In LyX, we already mark the language of the text, so it does not make much > sense to use that algorithm. I see. Basically I'm wondering if we can remove code that we have to maintain in favour of code that the fribidi people have to maintain. > Yes, some parts of encodings.C can be done using some external library. OK, thanks. What parts cannot ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: bidi stuff (Dekel ?)
On Wed, Jul 30, 2003 at 07:47:58PM +0100, John Levon wrote: > > I see. Basically I'm wondering if we can remove code that we have to > maintain in favour of code that the fribidi people have to maintain. It is rather short, and with external libraries you might have API changes.. > > > Yes, some parts of encodings.C can be done using some external library. > > OK, thanks. What parts cannot ? Don't know
Re: bidi stuff (Dekel ?)
On Wed, Jul 30, 2003 at 10:43:53PM +0300, Dekel Tsur wrote: > It is rather short That's true but it's also : 1) understood only by one person 2) right in the middle of some complicated code regards, john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
bidi stuff (Dekel ?)
I'm a bit confused why we seem to have our own (incomplete) support for bidi stuff. Is there a good reason we're not using fribidi or equivalent ? In particular we seem to have fairly hackish support via things like auto_number instead of properly implementing the unicode bidi algorithm and supporting the implicit LTR/RTL markers. Dekel, can you clarify the situation here please ? Finally, seeing as you're likely to have a pretty good grasp of the needed unicode work, can you give your thoughts on where we should go from here ? encodings.C *seems* to be an incomplete encoding conversion thing for the specific arabic etc. charsets. Why aren't we using libiconv ? This stuff is very new to me so I might be misunderstanding things quite majorly here. thanks john
bidi stuff (Dekel ?)
I'm a bit confused why we seem to have our own (incomplete) support for bidi stuff. Is there a good reason we're not using fribidi or equivalent ? In particular we seem to have fairly hackish support via things like auto_number instead of properly implementing the unicode bidi algorithm and supporting the implicit LTR/RTL markers. Dekel, can you clarify the situation here please ? Finally, seeing as you're likely to have a pretty good grasp of the needed unicode work, can you give your thoughts on where we should go from here ? encodings.C *seems* to be an incomplete encoding conversion thing for the specific arabic etc. charsets. Why aren't we using libiconv ? This stuff is very new to me so I might be misunderstanding things quite majorly here. thanks john
