On Sun, 3 Mar 2002 14:31:08 +0100 
  Olivier Chapuis <olivier chapuis free fr> wrote:
> 
> On Sun, Mar 03, 2002 at 12:16:40AM -0800, Nadim Shaikli wrote:
> > --- Olivier Chapuis wrote:
> > > So it seems to me that fribidi is useful only if the locale
> > > charest is UTF-8 (or when the user specify an iso10646-1/UTF-8
> > > font) as there is clear specification for bidi UTF-8 string.
> > > 
> > > Nadim, any opinion? As you ask for bidi support in fvwm can
> > > you explain in some details where are the problem with fvwm
> > > for a user which needs bidi.
> > 
> > >From what I understand, having Bidi enabled at all times should/will not
> > alter current display of latin characters.  In other words, let's assume
> > you've setup fvwm to display menu/title/pager/etc with English/French
> > characters, if you then opt to enable Bidi (in this instance the fribidi
> > library), then all your fribidi output will amount to be exactly the same
> > as the input - ie. you will not see a change.  If, on the other hand, you
> > had a title string "english, french, ARABIC" then you make a call to
> > fribidi, it will return "english, french, CIBARA" (reversing the Arabic -
> > which is what you'd want).  I don't see why the locale is relevant - I
> > can type-in my menu titles and xterm titles in .fvwmrc using a bidi editor
> > and invoke fvwm irrespective of locale and should be able to see correct
> > rendering of the titles, reversed and everything (like they where when I
> > entered them in the Bidi editor).
> 
> The locale is relevant I think but not directly what is really relevant
> is the font charset. fvwm has to know if your config files is written
> using UTF-8 encoding or ISO-8859-{6,8} or an LRT encoding.

It would be a wise move to switch over to dealing (and converting)
everything into UTF-8, no ?  You can almost surly and blindly make the
assumption that any Arabic (and most other languages) written on
linux/unix will be UTF-8 (that's a very fair and acceptable assumption
to make that is very much a standard way in dealing with multibyte matters).
There is certainly some overhead, but its definitely the right way to go
and will payoff in the long run when someone will want to display Chinese
on their titles/menus for instance :-)

> In other word, when fvwm have a string to display it cannot discover,
> by just examining the string, which encoding is used (or more precisely
> I do not know if this is possible and I do not think so).

Its very possible and is the norm in a UTF-8 context; virtually all
editors (vim is a good example with some useful sample code) do that.

>                                                             Moreover,
> fvwm use the X font that the user specify to display text so what
> we need is to use the font charset to decide if we need to use
> the fribidi filter (which is more or less the locale charset with
> multibyte support). For example, if we have the string "english, french,
> ARABIC" for a menu title and the Menu font is an ISO-8859-1 font the
> displayed string should be "english, french, ARABIC" as if the Menu font
> is an (imaginary) capRTL font it should be "english, french, CIBARA".

I don't see it that way - simply put, convert the UTF-8 UCS2 (or UCS4)
to its equivalent integer lookup and query the font(s) tables for the
glyph (the font should certainly be loaded in the Font Path (xset -q)).
Again, having bidi enabled at all times (ie. filter always ON) should not
result in any adverse affects in dealing with latin characters.

I might be coming from a biased view of life in thinking that all
characters are UTF-8, as such let me know what you think.

Thanks...

 - Nadim (please CC - I'm an archive reader)


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.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]

Reply via email to