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 ادريس سماوي حامد <[email protected]> > Salaam, Vafa, all > > On Tue, 19 Jul 2011 02:24:02 -0600, Vafa Khalighi <[email protected]> > 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 > >
