On Sat, 8 Mar 2003 07:52:14 +0100, Olivier Chapuis wrote:
> On Fri, Mar 07, 2003 at 04:39:16PM -0800, Nadim Shaikli wrote:
> > --- Marcus Lundblad wrote:
> > >
> > > [snip]
> > >
> > > I think using a precomposed form, if defined and available and
> > > superimpose otherwise is a good idea.
> > >
> > > By the way, how general is the shaping and joining code you wrote? Some
> > > other alphabets (besides Arabic) could make use of this (perhaps in a
> > > modified variant).
> >
> > Its generic and includes various other languages as well beyond pure Arabic
> > (note the header on FBidiJoin.c).
> >
> > The substitution you note for the example discussed earlier would be a very
> > simple addition if my memory hasn't failed (add the appropriate encodings
> > to the 'shaped_comb_table' array). The only catch there is you need to
> > compile fvwm with fribidi with the appropriate flags defined, etc.
> >
> > Its good to see there are other benefits from the code at hand (I knew
> > there would be :-). I'm sure the composing character superimposing (once
> > implemented) will also open a flurry of other much needed and missed
> > uses/languages as well as entice a number of new users to convert.
> >
>
> So if I well understand, FBidiJoint.c should be updated to handle
> some "composing char". Nadim can you send a patch? An other issue
> is that FBidiJoint has nothing to do with bidi and it should be use
> even if libfribidi is not detected?
Actually FBidiJoin and libfribidi are very much coupled at the moment.
A couple of things to note. Arabic and various other languages (those
derive from it or behave like it) require the following,
1. Bidirectionality (bidi for short - ie. displaying right-to-left)
2. Shaping (chars look different depending on location within word)
3. Combining (taking 2 characters and substituting them with one)
4. Composing ("superimposing" - draw one character on top of another)
FBidiJoin with the help of Fribidi does the first 3 requirements (I didn't
know how to code-up the 4th or I would have done it :-); other languages
might require a subset. What Marcus has pointed out is that there are
instances in which #3 above will need to be done without regard to anything
else. Adding those new mutations that have nothing to do with the first 2
rules (and bidi specifically) seems like it would create more confusion then
its worth on the code as it stands now (I'm also sure that Marcus would like
to see #4/composing as well). The way the code is currently structured,
the first 3 requirements are all rather intertwined (note "FriBidiChar").
In short, it would be logical to break out each of those functions into
their own function-call or whatever (if need be) and have them be
self-sustained. You see, if you use fribidi, you are very likely to
require the other behaviors (note "HAVE_BIDI" defines).
> After that we should take care of the superimpose case. We need a
> converter which split an USC-2 or UTF-8 string into two "strings" str
> and
>
> {
> int position; /* position in the str of c */
> XChar2b c; /* USC-2 char */
> }
> superimpose_char *superimpose_str;
>
> Then we can easily change Flocale.c to draw these two strings when
> needed. Nadim or Marcus can you write such converter I will take
> care of the integration into Flocale.c
I'm not sure I understand, I'll try to come back to this as time allows
later (but more explanation would certainly help).
If you guys (Marcus/Oliver/etc), on the other hand, get to this before me
then Great :-)
PS: Please CC replies
- Nadim
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
