[luatex] Fribidi for LuaTeX

[Khaled Hosny]

On Tue, Jul 19, 2011 at 11:21:20AM -0600, Idris Samawi Hamid ادريس   سماوي حامد wrote:
> 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.

Though I'm generally OK with a lua solution, I don't see how the choice
of numerals has any effect on the choice of bidi implementation.

> 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.

The algorithm actually has a dedicated rule of this use case:
  http://www.unicode.org/reports/tr9/#Higher-Level_Protocols

Regards,
 Khaled

-- 
 Khaled Hosny
 Egyptian
 Arab