Hi Behdad,
thanks, I found that very helpful. > But things are not so easy, the Arabic Joining Alg. > itself needs the "Left" and "Right" character of a character in text, > which Left and Right are defined in the visual text, not logical, the > left and right characters cannot be found easily from the next and > previous character of the logical order, because of the override marks > (LRO and RLO). Its not just the LRO/RLO, but all embeding level boundaries, since there the character on one (visual) side of the character being shaped is unrelated to the next/prev. logical character. > Example: > <LRO> a b C D <RLE> f g H <PDF> x Y z <PDF> > => <LRO> z Y x <RLE> f g H <PDF> D C b a <PDF> > also <LRO> a b <RLO> f g <PDF> h <LRE> x y <PDF> Z <PDF> > => <LRO> Z <LRE> x y <PDF> h <RLO> f g <PDF> b a <PDF> If I have a logical sequence abcKLMxyz (caps = RTL, overall LTR), then visual: abcMLKxyz, i.e., the visual left and right of K and M cannot be worked out in the logical space because 'c' is no way related to 'x' and 'L', and 'x' is in no way related to 'c' and 'L'. If the joining algorithm is defined in visual space, then I do not see how you can get around having to completely reorder first. > The first idea needs some work to prove the independency (which > may not be true). Shaping is _not_ independent of line breaking, here is why: (1) Unidirectional text: the BIDI transformation does not change the visual sequence of glyphs, but just the orientation of the coordinate system from which it is observed, i.e., the context of individual characters remains identical. Line breaking makes no difference here, since it does not impact the visual ordering (the individual lines are mere snapshots of segments of the 'original' single long (visual) line). (2) true bidi text: (1) applies to all characters except those on direction boundary. For the characters on the boundary, we have two cases: (2a) character starts an embeding level: the context given by the next (logical) character, and the last (logical) character of the preceeding embeding level (2b) character ends embeding level: the context given by the previous (logical character), and the first (logical) character of the next embeding level. Now, the line breaking here does not change the visual sequence of the text if the line break falls withing a segment of visual direction identical to the base direction, it has exactly the same effect as in case (1). If the line break falls into a segment with a different visual direction than the base direction, the visual order of glyphs is impacted (we no more have simple snapshots of segments of the original long visual line). The question of whether this has any impact on the shaping then boils down to one thing: is the contextual value of the glyph immediatelly before the last embeding level change on the previous line identical to the contextual value of the character on which a line break is allowed. If it is (A), then the joining is independent of line breaking. If it is not (B), then joining is affected by line breaking: abcKLM OPQ xyz => abcQPO MLK xyz with line between M and O: abcMLK QPO xyz i.e., the origianal line would have had medial Q and final M, the new line has medial M and final Q. In theory (B) is entirely legitimate, and so joining is not independent of linebreaking. In real life, the assumption that (A) is true will often be satisfied, because we can expect a character such as space on the embeding level boundary. It seems to me that the only way to completely resolve the circular dependence here is by defining the joining algorithm in logical space. Tomas But the second one which is a bit complex > seems to produce the desired result. I will provide the test > cases for different cases in another mail. > > [End of BiDi vs. Arabic Joining interaction material, the rest is > fribidi related.] > > B. Our implementation of the Arabic Joining Algorithm is quite > small and light, that will not harm the objectives of fribidi at all, > but makes it much more useful, either the command line tool (that can > be used to cat right to left files), and the library. Many > applications that use fribidi do not support Arabic Joining as there > is no light-weight implementation of it availble, or the author just > wanted it to work for hebrew. But with Arabic Joining in fribidi the > developer can just easily turn the arabic joining on to work well for > arabic too. > > C. The Pango is not a real solution for the audience of fribidi: > fribidi has been ported to some mobile devices. Also fribidi has been > used on linux console and xterm, that is not a good idea to use pango > for arabic joining there. fribidi is mostly used for hebrew and > arabic scripts, which their rendering will be completed with arabic > joining algorithm, then we should not worry about other shaping > matters, when shaping of all the Unicode characters is needed, the > fribidi feature can be turned off. > > D. Using the Unicode Arabic Presentation Forms is also essential with > Linux console, as the kernel maps the Unicode codepoints to glyphs, > for other scripts like syriac which does not have the presentation > forms in unicode, their presentaion forms should be registered in the > private area of unicode (H. Peter Anvin is responsible for registering > them in linux), to be able to show them in linux console. > > E. About the overhead of it on fribidi, I believe that the > hebrew community should not be so happy, but: > > 1. It can be fully turned out with a configure time > option. > 2. When compiled with Arabic Joining, by default its > off, the developer should turn it on if needed. > 3. I try to put it in a different binary to save the > resources. > > > I hope that with the above discussion there will be enough > reasons for all of you to put it in fribidi. > > Yours, > -- Behdad Esfahbod 6 Farvardin 1381, 2002 Mar 26 > <behdad at bamdad dot org> [Finger for Geek Code] > > > > _______________________________________________ > Fribidi-discuss mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/fribidi-discuss >
