[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
way.
Regards,
Khaled
--
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