[Fribidi-discuss] Bug in wrapping in command-line fribidi?

[Beni Cherniavsky]

The command-line fribidi util (10.4) seems to do wrapping in the most
non-sensible way imaginable:

$ echo ABCDEFGHIJKLMNOPQRSTUVWXZY | fribidi -w 10 --caprtl
YZXWVUTSRQ
PONMLKJIHG
    FEDCBA
$ echo ABCDE fghijklmnopqrstu VWXZY | fribidi -w 10 --caprtl
YZXWV fghi
jklmnopqrs
  tu EDCBA
$ echo abcde FGHIJKLMNOPQRSTU vwxzy | fribidi -w 10 --caprtl
abcde UTSR
QPONMLKJIH
GF vwxzy

The hebrew text is wrapped in opposide line order!  This is a result
of applying the wrapping on the visual string after the bidi instead
of doing it on the logical string before the bidi.  The later would do
the right thing, I think, even in complex cases when the logically
last word on the line should ge in the middle of the line:

$ echo ABCDE fghijklmnopqrstu VWXZY | fold -w 10 | fribidi -w 10 --caprtl --rtl
fghi EDCBA
jklmnopqrs
  YZXWV tu
$ echo abcde FGHIJKLMNOPQRSTU vwxzy | fold -w 10 | fribidi -w 10 --caprtl --ltr
abcde IHGF
SRQPONMLKJ
UT vwxzy

[BTW, anybody got a UTF-8 aware `fold`?]

The --ltr / --rtl are needed to force the base direction of the whole
paragraph to be the same, otherwise different parts of the same line
would be auto-detected with different directions.

A quick look at the source seems to confirm that wrapping is done on
the visual result.  The fix would be a bit involved.  In particular,
should the ltov, levels, etc. debugging outputs be shown separately
for every line after splitting or for the whole text?  Direction
detection can work by simply autodetecting first time and reusing
the value stored into `&base` for the next physical lines of the same
logical line.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>,
whose 12x CD burner works at 24x with cdrecord in linux - sheer magic!