[luatex] Fribidi for LuaTeX

[Vafa Khalighi]

Hi Idris

Agreed. and if you look ath my previous questions, I actually asked if it is
to be implemented in the luatex engine or in the macro level but I got no
clear response. I have no problems doing uni bidi in lua and that is what I
have been doing for a week but I have not finished yet. I am not going to
implement whole uni bidi for my package, just mirroring characters, numbers
are LTR, One single English word is LTR and that is it. Then I see what
users say and then change things as need arises.

Thanks

2011/7/20 Idris Samawi Hamid ادريس سماوي حامد <ishamid at colostate.edu>

> Salaam, Vafa, all
>
> On Tue, 19 Jul 2011 02:24:02 -0600, Vafa Khalighi <vafa018 at gmail.com>
> wrote:
>
>
>  True but at least I think luatex can provides something similar to  what
>> XeTeX provides by its ICU layout engine and the rest (which obviously is
>> much complicated and needs more testing) can be done either by a
>> preprocessor or done entirely in lua.
>>
>>
>> Which thereby makes a generic solution impossible. Omega translation
>>
>>> processing struggled with this mix of 'pure text', 'macro expansion',
>>> 'packages content' and it never worked out in complex situations. For me
>>> this is a pretty good reason for not adding any hard coded bidi (or foo
>>> or
>>> bar or whatever) behavior to core luatex but stick to either external
>>> libraries (preprocessing or whatever) and/or solutions written in lua
>>> that
>>> nicely interact with the macro packages concepts. (Well, that's the main
>>> reason for having lua as extension language in the first place).
>>>
>>
> I am feeling deja vu here ;-)
>
> We must all remember that luatex has a different philosophy from xetex
> etc. luatex provides the most basic, low-level, bi-directionality as
> perfectly as possible.
>
> OTOH, luatex is _not_ interested in deifying any particular paradigm of
> rules for processing bidi text. Compare with the Open Type engine: That's
> done by lua extensions. Similarly, bidi in mkiv will be done by lua
> extensions which can easily be modified and parameterized as needed.
>
> For example, I may want to use Arabic-numerals in a Persian-typesetting
> context or vice versa. Hardcoding the bidi algorithm makes that
> inconvenient. Also, the bidi algorithm is not perfect: it mixes the needs
> of an editor or verbatim mode with those of real life typography. These
> features should be flexible and capable of being turned on and off.
> Consider an Arabic paragraph that's all in Arabic except the first word in
> English. It makes no sense to force an LR par in that case.
>
> Sometimes you want to turn bidi features off, or at least deprecate them,
> in verbatim. See the features of SC Unipad -- perhaps the best
> implementation of the bidi algorithm -- for example.
>
> Parts of the bidi algorithm can be part of a solution to the overall
> question of bidi typography, but it makes more sense in the luatex
> philosophy to decouple that algorithm from the core and build a bidi
> paradigm -- or even paradigms in the plural -- than to hardcode one.
>
> For those who like the xetex paradigm, it's best to use xetex. xetex and
> luatex involve different philosophical approaches. Using lua, anyone
> interested can develop their own bidi engine on top of luatex. Similarly,
> if someone does not like the way mkiv does open type. it's just a matter
> of writing another OT engine in lua instead of recompiling luatex.
>
> Best wishes
> Idris
> --
> Professor Idris Samawi Hamid, Editor-in-Chief
> International Journal of Shīʿī Studies
> Department of Philosophy
> Colorado State University
> Fort Collins, CO 80523
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/luatex/attachments/20110720/21cbbe5b/attachment-0001.html>