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

[Dov Grobgeld]

On Tue, Mar 25, 2003 at 12:24:11AM +0200, Beni Cherniavsky wrote:
> For processing huge lines (possible use case: consider an editor
> working on a logical line that is so long that it doesn't fit the
> screen) we only need to split step 1.  Perhaps this can be solved by
> exposing a state structure (probably a stack of embedding levels?)
> that can be passed from one line segment to the next.  How much
> lookahead do we need to resolve the levels?  I'm afraid this can't
> work at least because we need to guess the base direction.

I just finished writing such a patch for the gtk text widget. Please
see: 

    http://bugzilla.gnome.org/show_bug.cgi?id=70451

I'm indeed passing the base direction back and forth between the 
paragraph. Btw, in order to do this, I had to add a new function to
fribidi, that returns the base direction of a paragraph.
 
> Which reminds me, there should be a separate function exposed for just
> auto-detecting the base direction.  This will allow the application to
> intervene and supplement this auto-detection (currently I think it
> sometimes involves re-running the whole log2vis process).  Custom
> algorithms might benefit from a separate step that just detects the
> character categories...

See above.

> In general I think as many separate processing stages should be
> exposed as possible.  For example a program might understand some
> "higher-level protocol" and wants to express this knowledge to
> fribidi.  I think that can be done by supplying initial levels for the
> characters (and fribidi can increase them according to implicit rules
> and explicit marks...).

It don't think it makes sense to carry the bidi level between paragraphs.
But fribidi does already allow using a "high level protocol" for 
determining the base direction. It is implemented by the 

        FriBidiCharType *pbase_dir,

parameter of the fribidi_log2vis() call. If *pbase_dir is set to
FRIBIDI_TYPE_LTR or FRIBIDI_TYPE_RTL, then that is the base direction
of the paragraph. If on the other hand it is set to FRIBIDI_TYPE_WL
or FRIBIDI_TYPE_WR then the direction will be LTR or RTL only if 
no strong characters are found in the paragraph. Thus the pseudocoe
for resolving a whole text (according to the algo that I used in 
the gtk_text_viewer widget is):

        1. Find first strong character in whole text. That becomes
	   the bidi dir of the first paragraph.
	2. Loop over each paragraph:
	     1. Find bidi dir of paragraph. Input *pbase_dir is the
	        weak version of the current bidi dir.
             2. Layout according to bidi dir.

The result is that weak paragraphs inherit the direction of the previous
paragraph.

I actually think it is unfortunate that the Unicode bidi dir doesn't
define this behaviour, but only speaks of a "higher level protocol". 

> Wait a moment!  The fribidi API was derived from a document describing
> Mozilla's requirements, wasn't it?  Now mozilla does line splitting,
> with varying fonts and perhaps kerning complications, higher-level
> protocol (span dir=...), arabic shaping, etc. - a complete nightmare.
> How do they do it?

Not with fribidi... But really all you have to do what you said:

  1. resolve levels
  2. split lines
  3. reorder all odd bidi levels
 
> [On varying fonts: I think that in some corner cases the points of
> line-wrapping can't be determined until you know the visual order,
> because of font/char-dependent spacing at segment boundaries;
> TeX-style global line breaking with hyphenation probably introduces
> even more complications...  I wonder whether anybody ever tackled this
> and whether fribidi should take this into consideration.  I guess any
> programmer would give up such precision in return for his sanity. :-]

Actually I think that the order above solves that. What makes things
really insane is kerning at bidi directional boundaries. But that 
may safely be ignored I belive. 8-)
 
Regards,
Dov

> -- 
> Beni Cherniavsky <cben at tx.technion.ac.il>,
> whose 12x CD burner works at 24x with cdrecord in linux - sheer magic!
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Fribidi-discuss mailing list
> Fribidi-discuss at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fribidi-discuss