[luatex] Vital RTL issues in LuaTeX

Khaled Hosny khaledhosny at eglug.org
Fri Apr 10 14:06:38 CEST 2009

On Fri, Apr 10, 2009 at 01:41:08PM +0200, Yannis Haralambous wrote:
> Le 10 avr. 09 à 13:29, وفا خلیقی a écrit :
>         I, personally, don't think we need to code any thing at the engine
>         level, this just make things more complex and less flexible, lets take
>         the example Taco pointed out, if we applied bidi algorithm on 3.5
>         (chapter 3, section 5) it'll stay 3.5 regardless of text direction,
>         however it should be 5.3 in RTL, and some people might disagree and say
>         it should be 3.5 in all cases. If BiDi was hard coded in th engine,
>         it'll
>         just make things more complex, and one will need to put a Unicode
>         'right
>         to left mark' before the dot. The same can be said for numbered lists
>         etc.
>     You picked up the very wrong example. That is all I can say.  No,
>     absolutely the same can not be said about numbers and etc.
> Bidi algorithm is certainly not perfect but it handles most cases correctly and
> it gives you the possibility to force a given directional behaviour, if needed.
> The BIG advantage of the bidi algorithm is that it is a standard. Every piece
> of software will represent the same Unicode string in the same way. For
> example, if you keyboard your text using a bidi-compatible text editor, then
> you will get the same output as what you'll see on your screen. And once you
> get used to the behaviour of text with respect to the five bidi special
> characters, then you can keyboard RTL languages in the same way everywhere.
> That's an improvement to previous input methods.

I completely agree, I never said otherwise, it is where to implement
bidi algorithm in the engine, or using lua code? I say we use lua, this
means less complexity in the engine and more flexibility for the macro
writer, and then we can consider higher level protocols in a simpler


 Khaled Hosny
 Arabic localiser and member of Arabeyes.org team
 Free font developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://tug.org/pipermail/luatex/attachments/20090410/6641eb31/attachment.bin 

More information about the luatex mailing list