basic bidi support using perl

Moshe Kamensky samvimes at fastmail.fm
Tue Aug 22 23:05:57 CEST 2006


* James Cloos <cloos+rxvt-unicode at jhcloos.com> [22/08/06 05:52]:
> >>>>> "Moshe" == Moshe Kamensky <samvimes at fastmail.fm> wrote:
> >>>>> "Marc"  == Marc Lehmann   <schmorp at schmorp.de> wrote:
> 
> Moshe> I added basic bidi support, using the perl interface and the
> Moshe> perl FriBidi module:
> 
> Marc> Wow, what a wonderful hack! And so small!
> 
> Indeed!  Way cool.

Thanks. Of course, the actual work was done by others :) It was a 
pleasant surprise to discover a terminal with perl support, and this is 
was the first application that came to mind.

Anyway, I realised there is another problem of this script - it doesn't 
work when the line length is more than the width of the window. I didn't 
manage to find any documentation of libfribidi, but it seems that the 
part of the algorithm that is concerned with multi-line displaying is 
not implemented at all.

To solve both this problem, and the rendition, it is necessary to have 
the rest of the output of log2vis, which is not available in the current 
FriBidi.pm. I just finished writing a swig interface file for log2vis, 
and I think that the rest can be written in perl without much 
performance lost. This should solve the rendition problem, and the long 
lines.

I think that the selection problem should also be easy to solve, but I 
didn't manage to understand how to change the selection boundary.

As for editing, this another story ...

> 
> Marc> I think (from my limited knowledge) that the only "correct" way
> Marc> to implement this is to store text in transmission order and
> Marc> only apply bidi when displaying it, which is not trivial.
> 
> That is correct.

As long as the line is displayed only once, that's what we are doing.  
For editing, this is what should be done.

> 
> Marc> I do plan to implement this by relying on pango at one point,
> Marc> though, merely storing a flag per line wether it is "complex"
> Marc> (== needs a complex layouter like pango) or "simple" (== can
> Marc> use urxvts algorithms).
> 
> The FriBidi perl module links against libfribi (cf: http://fribidi.org);
> you can call it directly from the C++ as well.  (It is C++ friendly.)
> 
I don't know exactly what pango can do better than fribidi, but I did 
notice that it has a performance hit. I think that fribidi is pretty 
fast, and I'm not sure that deciding where to turn on this flag is so 
simple. It may involve implementing some of the bidi algorithm ...

> Pango uses it for the bidi stuff, too, so it is a good stepping stone
> to full shaping capability.
> 
> Although, I do wonder how much shaping a terminal requires?  Is there
> a way to help out simpler apps while not getting in the way of apps
> which already know how to do shaping?

I know nothing about shaping, but I think that the fribidi people are 
working on this (at least, it is listed as their main goal.)

Thanks,
Moshe

> 
> Marc> That way, I could move the complexity into pango (which is
> Marc> likely better maintained than I could do it) while maintaining
> Marc> normal speed.
> 
> Good call.
> 
> And kudos again to Moshe.  Cool script!
> 
> -JimC
> -- 
> James Cloos <cloos at jhcloos.com>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20060822/3a20ed53/attachment.sig>


More information about the rxvt-unicode mailing list