Subject: Bidi status/help

From: Nadim Shaikli <[email-masked]>
Date: Thu, 18 Apr 2002 16:37:00 -0700 (PDT)

Mikhael/Olivier, I downloaded a recent snapshot (20020416) to test
out the Bidi code that was recently added.  I compiled with fribidi;
everything went smoothly - configure noted,

  With Bi-directional text support?   yes

yet I'm not sure how to go about displaying a window title in Arabic.
I tried the following,

  Using a 10646 font (its used successful in many other applications),
  I defined the following entries in my fvwm2rc file,

  Style * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1

  AddToMenu arabic-test
  + "Arabic" Title 
  + "ar-test"    Exec exec xterm -title �?رحبا -e rsh otho &
  + "�?رحبا"  Exec exec xterm -title test -e rsh otho &

  In my .xinitrc prior to starting fvwm2, I 'xset fp+ my_10646_font_file',
  I then start fvwm2; I invoke that "ar-test" entry, the xterm appears,
  but the title is NOT displayed in arabic.  The menu entry is not noted
  in Arabic either.  Do note that the environment is set so that I can use
  other applications that require the Bidi library and the 10646 font (so
  they're very much loaded - I hope I don't need to muck with locales and
  such :-)

What am I missing (and/or doing wrong).  The documentation (fvwm.1)
along the lines of usage are somewhat lacking and so I'm wondering
if you could give me some snippets of things that have worked for ya
(ie. some guidance).

Regards,

 - Nadim

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 19 Apr 2002 01:21:55 +0000

On 18 Apr 2002 16:37:00 -0700, Nadim Shaikli wrote:
>   + "ar-test"    Exec exec xterm -title Ù?Ø±Ø­Ø¨Ø§ -e rsh otho &
>   + "Ù?Ø±Ø­Ø¨Ø§"  Exec exec xterm -title test -e rsh otho &
> 

I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
I suppose Olivier knows.

I only tested 8-bit encodings, iso8859-6 and iso8859-8.

Do the following. Install iso8859-6.8x fonts from:

  http://www.langbox.com/bidimozilla/fontXFE/

Do the same with iso8859-6 fonts in old/ subdirectory.
Run xmessage from a script (if 8-bit chars can't be typed in your shell):

  xmessage -name "a) ÓáÑ - Åâäêåê, Î×è× ÌèêÉ" "this message is not really important, just long enough"

I don't know what the string means, I copied it from some web site.
Do the following:

  Style Xmessage Font *-iso8859-6     # Bidi applied, visual Arabic
  Style Xmessage Font *-iso8859-6.8x  # Bidi not applied, logical Arabic

The same with Hebrew:

  xmessage -name "a) îùôè áòáøéú" "this message is not really important"
  Style Xmessage Font *-iso8859-8     # Bidi applied, visual Hebrew

I tried to add now iso8859-6.8x as bidi-enabled in libs/FlocaleCharset.h,
but it failed. I tried all cases including "iso8859-6.8x" (what fonts.dir
says), "iso8859-6.8X" (what pcf says), "iso-8859-6.8X" (what url says),
nothing works. Olivier, what should be done?

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 24 Apr 2002 06:56:05 +0200

> >   Style * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1

Nadim, can you send me a pointer to a doc about the "full10x20" notation
for loading iso10646 font?

> >   AddToMenu arabic-test
> >   + "Arabic" Title 
> >   + "ar-test"    Exec exec xterm -title Ù?Ø±Ø­Ø?Ø§ -e rsh otho &
> >   + "Ù?Ø±Ø­Ø?Ø§"  Exec exec xterm -title test -e rsh otho &
> > 

It seems that there is two problems here.
- Displaying  string with a core *-iso10646-1 font: at the present
time this should work only with fvwm compiled with MB support, an utf8
locale and a libc that support utf8 locale (also X should reconize
the locale as an utf locale: see /usr/X11R6/lib/X11/locale/loacle.alias).
Unfortunately, I cannot test this as my libc does not support utf8
locale. Mikhael, can you confirm that this work?
- To apply bidi fvwm should reconize a core *-10646-1 font, I think
that fvwm fail to do this because I think that the default charset
with the utf8 XFree-4 locale is iso8859-1. This may be fixed after
a confirmation that the first point work.

I will see if we can implement the use of core *-iso10646-1 font
without all the above requirement (but with XFree-4).

On the other hands, I think that with a true type iso10646-1
font there is no problem (needs XFree-4.x, x>=1 and iso10646-1
ttf with arabic/hebrew/persian characters to see bidi in work)

> nothing works. Olivier, what should be done?

Hum ..., do you try to add the line
	CT_ENTRY("ISO8859-6.8X",       iso8859_6,           "ISO8859-6")
at the end of the FlocaleCharsetTable[] initialization (around line 338
of libs/FlocaleCharset.h)?

What is the difference between ISO8859-6 and ISO8859-6.8X ?

Olivier

---

From: Nadim Shaikli <[email-masked]>
Date: Wed, 24 Apr 2002 12:41:38 -0700 (PDT)

On Wed, 24 Apr 2002 06:56:05 +0200,
  "Olivier Chapuis" <olivier chapuis free fr> wrote:
> > >   Style * Font
-misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1
> for loading iso10646 font?

I'm not sure what you mean by "loading the 10646 font", but you can
download the non-truncated 10x20 font using the link(s) below,

  http://www.arabeyes.org/download/external/vim/10x20.bdf.gz
   -or-
  http://www.arabeyes.org/download/external/vim/10x21.pcf.Z

Note: the internal names of the fonts within the files might differ,
      please check 'mkfontdir' output (fonts.dir) for appropriate
      names -- if you have problems, don't hesitate to let me know.

> > >   AddToMenu arabic-test
> > >   + "Arabic" Title 
> > >   + "ar-test"    Exec exec xterm -title �?رح�?ا -e rsh otho &
> > >   + "�?رح�?ا"  Exec exec xterm -title test -e rsh otho &
> > > 

Well, I'm not sure why all that is needed (I'm simply trying to display
a few glyphs not alter my keyboard mapping, or specify date/currency
settings, etc).  By the way, I'm able to use multiple Arabic-enabled
utilities without having to touch any of what is noted above (locales,
libc support, etc) given the availability of the fonts and a rendering
engine (glyph displayer) and Bidi (fribidi) - one such application is
vim-6.0/6.1.

On the same related-topic what about those that are not running linux
per se, but are using various unix flavors (at work, for instance, I'm
on a Sparc Solaris (SunOS-5.7)).

Thanks & let me know if you need more info.

 - Nadim (please continue to CC for a faster response :-)

Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 24 Apr 2002 18:15:49 +0000

On 24 Apr 2002 06:56:05 +0200, Olivier Chapuis wrote:
> > >   In my .xinitrc prior to starting fvwm2, I 'xset fp+
> > >   my_10646_font_file', I then start fvwm2; I invoke that "ar-test"
> > >   entry, the xterm appears, but the title is NOT displayed in
> > >   arabic.  The menu entry is not noted in Arabic either.  Do note
> > >   that the environment is set so that I can use other applications
> > >   that require the Bidi library and the 10646 font (so they're very
> > >   much loaded - I hope I don't need to muck with locales and such
> > >   :-)
> > 

Hmm, not yet.

My glibc-2.2.90 does not support utf8 locales (I don't know how .90 is
possible if the latest is 2.2.5).

I upgraded to glibc-2.2.5. This broke all my programs that use atexit(),
I don't know why they did it. Anyway, glibc-2.2.5 supports utf8 locales.

XFree86-4.1.0 does not seem to support utf8 locales, at least I added
as you suggested these lines to locale.alias, it does not work.

  ar_JO.utf8   ar_JO.UTF-8
  en_US.utf8   en_US.UTF-8
  he_IL.utf8   he_IL.UTF-8
  ru_RU.utf8   ru_RU.UTF-8

So I upgraded X to XFree86-4.2.0. The same result.
Xlib does not support locale en_US.utf8. Ideas?

> of libs/FlocaleCharset.h)?

I tried to extend the iso8859_6 definition instead. Now it works.

> What is the difference between ISO8859-6 and ISO8859-6.8X ?

I don't know. Probably there were a revision of a charset specification.
I am still waiting for a confirmation that bidi works correctly for both.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 25 Apr 2002 00:36:58 +0000

> Xlib does not support locale en_US.utf8. Ideas?

Ok, changes to locale.alias do not work, but if I use the locales from the
right column, both glibc and Xlib support them.

I am now experimenting, the main problem is that I don't have true unicode
fonts, specifying "*-iso10646-1" gives some subset.

I also get this behaviour. When running with LC_CTYPE=en_US.UTF-8 and I
specify incorrect font, it may wait several seconds. Error messages are
not polished. I will try to improve them a bit later.

*-iso8859-1 font gives this: "*T*i*t*l*e" where "*" is empty square, while
*-iso8859-N (where N is from 2 to 15) shows it right: "Title". Why is it?

> > ttf with arabic/hebrew/persian characters to see bidi in work)

When I use:

  Style * Font "xft:Luxi Mono:Medium:Roman:size=14:encoding=iso10646-1"

only latin is displayed, but I can see where are spaces and see that Bidi
is applied to Arabic/Hebrew in utf8.

I use this app for testing (where ar_JO may be replaced by he_IL, ru_RU):

  xmessage -name "`env LANG=ar_JO.UTF-8 date '+%a %d/%b/%Y'`" nothing

When I use (fvwm is still run under LC_CTYPE=en_US.UTF-8):

  Style * Font *something_from_426_unicode_fonts*-iso10646-1

it works as expected except that I don't have unicode fonts for Arabic
(*-arabeyes-1 seems unusable at all, and another my *-iso10646-1 has only
Arabic, not latin). I am able to see Russian and Hebrew without problems.
Bidi works well with utf8.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 25 Apr 2002 08:02:11 +0200

> right column, both glibc and Xlib support them.

It seems that XFree-4 has only one utf8 locale en_US.utf8 and that
there are at the present time discussion/problems ([email-masked])
on how this locale force font loading ...

> fonts, specifying "*-iso10646-1" gives some subset.

Yes, it seems that XFree  *-iso10646-1 fonts contains only a few part
of the all iso10646-1 characters. An other problems is that I think
that when you load a core X font all the characters are loaded, this
can cause memory problems. I think there is a way to load only
a part of an iso10646-1 font as iso10646[blabla]-1 or someting like
this I need to re found a doc on this.

> *-iso8859-N (where N is from 2 to 15) shows it right: "Title". Why is it?

I do not know.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 25 Apr 2002 23:26:17 +0200

>       names -- if you have problems, don't hesitate to let me know.

The problem here is that the end of an X font name should/must be
the charset. So I was/am surprised by "full10x20-1". So it seems
that full10x20 denote a font size ??? If this is the case I suggest
that you send a bug report to  http://www.arabeyes.org/ :o)

> > > >   AddToMenu arabic-test
> > > >   + "Arabic" Title 
> > > >   + "ar-test"    Exec exec xterm -title ?????????? -e rsh otho &
> > > >   + "??????????"  Exec exec xterm -title test -e rsh otho &
> > > > 
> my_10646_font_file',

Yes and you use a special font made for vim ... Maybe you start vim with
some options? Moreover, I think that vim use an other method than fvwm
to display strings. Also some applications (KDE2&3/GNOME2) use only utf8,
but this is not possible with fvwm (we cannot ask everybody to use only
utf8 in configuration files). Moreover, most of these applications use
(lib)iconv which can cause portability problem (basically we should also
ask everybody with a non (or old) GNU system to install gnu libiconv).

Here the problems:

1 - if we want to make some bidi conversion on a string we _must_
know the encoding used by the string. The only good general method I
found is to look at the font name of the used font and to extract
the charset/encoding from this name. There is a precise specification
here from the X Consortium, the last two "items" of a font name should
be the CHARSET_REGISTRY and the CHARSET_ENCODING. Then, if you use
a font which does not respect this standard no conversion will be
done. If you use a font which use a strange charset name as say
"my_arabic-36" we may "fix" fvwm so that fvwm understand this
name in one second (if it correspond to an encoding that fribidi
support). This may become configurable in a special way in the
future. A simple alternative would be to add a new fvwm Style
(and new module config options) to specify the charset of the
font ... (basically xterm use this method with the  -u8 option),
but I do not like so much this idea. I prefer that the font
define the encoding used by the user.

2 - After fvwm have determined the charset and load the font it should
display the string (forget bidi here). With an unibyte font (as iso8859-X)
there are no problems. Why do you not use iso8859-6 fonts with fvwm?
Do you need others characters than ASCII and Arabic one's?
With a multibyte font (as iso10646) locale is important, as fvwm use a
(powerful) method from X to display string and load font. Good fonts
are automatically loaded (no need to specify the charset) and string
are well displayed without the need to think to much :o)
So with iso10646, at the present time, you should use an utf8
locale (or good ttf font and XFree-4.good_version, here yet an
other method is used).

Now as utf8 grow in importance and a lot of system does not support
utf8 locale I will see if fvwm can support utf8 on system which does
not support utf8 locale. You may be happy with this but you should
wait a bit. Ooops, this works now on my machine but I cannot commit
the change before Monday, this should work on any X server (I have
added a 4th method to display string ...).
 
> on a Sparc Solaris (SunOS-5.7)).

Fvwm is not written for Linux. We try to do so that fvwm can work
on any system that can run an X server. I hope that fvwm has no
problem with Sparc Solaris. However, some fvwm developers use Linux,
GNU tools/libs and XFree so it may happen that there are some problems
with "exotic" architecture (specially if there are not gnushed or/and
XFreed), but we always try to fix these problems.

Regards, Olivier

---

From: Nadim Shaikli <[email-masked]>
Date: Fri, 26 Apr 2002 18:07:37 -0700 (PDT)

On Thu, 25 Apr 2002 23:26:17 +0200,
  Olivier Chapuis <olivier chapuis free fr> wrote:
> >   "Olivier Chapuis" wrote:

[snip snip]

> ask everybody with a non (or old) GNU system to install gnu libiconv).

Just in passing, those fonts are not specific to vim and no special
options are needed to use 'em (ie. start options).  BTW, couldn't
those methods (libiconv and others) be things that could be included
during configure time ?

> define the encoding used by the user.

A couple of things -

a. You can run Bidi on any string irrespective of its encoding and
   it ought to work (only encodings that it cares about will be
   touched - namely 8859-6 and 8859-8) - so, unless I'm missing a
   detail, I don't see why fvwm needs to know the encoding of the
   strings at all (except in the case where it needs to display
   'em, of course :-)

b. I think we are discussing an optimization regarding the loading of
   the fonts, no ? Meaning, why not simply load all the fonts a user
   specifies even if it were a 10646 with english, russian, arabic,
   japanese, hebrew, chinese, etc when a user specifies "all" (or
   similar somehow within fvwmrc file)

> Do you need others characters than ASCII and Arabic one's?

Yup, Arabic requires Form-B glyphs rendering iso8859-6 useless for display.

In brief (beyond the realm of fvwm really, but you asked :-), Arabic has
complexities which few other languages have in which characters are
displayed differently based on their location within the word and sentence.
All files are stored with 8859-6 encodings, but for those applications
which don't use an external display engine (and most don't :-) one is
required to get the extra display glyphs from somewhere else (Unicode's
Form-B -- http://www.unicode.org/charts/PDF/UFE70.pdf).

> added a 4th method to display string ...).

OK, I think you are saying that with 10646 fonts the locale will
specify which subsections will be loaded and ought to be used as
the charsets to display within fvwm, right ?  What will a person
need to do in order to display say 4 languages (english, arabic,
japanese, russian) all within the same the 10646 font file - a
single locale won't suffice or will it ?  Seems like a more dynamic
solution ought to be sought.

Before I got this email, I was thinking more along a way to specify
the usage of utf8 within fvwm2rc (or fvwmrc :-); something along the
lines,

  Style * Charset utf8		// meaning all of 'em (*utf8* :-)
   -or-
  Style * Charset english:arabic:sv.UTF-8:iso8859-7

Just an idea.

> XFreed), but we always try to fix these problems.

Yeah I know.  I was just noting it as "food for thought" and
a "reminder" :-)

Thanks for all your help and your very helpful explanations.

 - Nadim

Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 27 Apr 2002 21:34:21 +0000

On 26 Apr 2002 18:07:37 -0700, Nadim Shaikli wrote:
> 
> On Thu, 25 Apr 2002, Olivier Chapuis <olivier chapuis free fr> wrote:
> >
> > > On Wed, 24 Apr 2002 06:56:05 +0200, "Olivier Chapuis" wrote:
> > > > 
> options are needed to use 'em (ie. start options). 

This is not quite correct. You add to .vimrc these lines:

  set guifont=-misc-fixed-medium-r-normal--20-200-75-75-c-100-arabeyes-1
  set encoding=utf-8

So you explicitly request utf-8. In fvwm it is currently determined
automatically by font and locale.

> BTW, couldn't those methods (libiconv and others) be things that could
> be included during configure time ?

libiconv is already auto-configure'd like any other non-portable thing.

> > define the encoding used by the user.

I think too that a font should define the encoding used by the user
(together with locale if a font information is not enough), although it
may sound strange. The logic is that a user would not use that font if it
is not suitable for his text to display.

An alternative would be to require to specify an encoding together with
every string. Or adding Encoding option. But in the end we will find that
a user should usually specify Encoding and Font in the same place (for
example in MenuStyle, or like with .vimrc), so there is a duplication.

>    strings at all (except in the case where it needs to display

Because a string "ÓáÑ" should only be Bidi'd if its encoding is iso8859-6,
but not koi8-r. Even vim should know string encoding (you specified utf8).

fvwm should also know to translate between charsets used by locales to the
ones fribidi_parse_charset knows about. For example on Solaris "8859-6",
on hpux "iso86", but fribidi_parse_charset knows only about "iso8859-6",
at least we can't risk. It also seems that fribidi does not know about the
iso8859-6.8x charset, still fvwm supports it. If you have any info on the
subject (fribidi or iso8859-6.8x), share it.

> Form-B -- http://www.unicode.org/charts/PDF/UFE70.pdf).

It is good to know that iso8859-6 is fully capable for storing Arabic
without a loss, I only knew that iso8859-6 glyphs are not enough for
displaying.

> solution ought to be sought.

I am not an autority, but I think that locale has nothing to do with
displaying different languages at once, it only defines a natural language
and other local properties that a user wants to pass to his applications.
I.e. with ru_RU.utf-8 /bin/date writes in Russian, with ar_JO.utf-8 - in
Arabic, still both outputs use the same unicode font.

I don't think that locale is used anywhere for font loading optimizations
although it may.

>   Style * Charset english:arabic:sv.UTF-8:iso8859-7

The first line is similar to the Encoding option I mentioned above,
but I don't understand what exactly should the second line do.
I see here natural language names, locale names and charset names. :)

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 29 Apr 2002 11:31:28 +0200

> options are needed to use 'em (ie. start options).

So I download your 10x20.bdf.gz vim font put it in a directory
arabic/, run mkfontdir and add arabic/ to my fonts path.
First, mkfontdir gives the following name to the font:

-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1

:o).

Secondly, is that I use current cvs which now support iso10646-1
without any requirement (you may try the "next" snapshot, but 2.5.1
does not work).
And the last thing is that every things seems to work. The test
I done:

MenuStyle * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
# replace /opt/kde to KDE3 dir
ImagePath +:/opt/kde/share/icons/hicolor/16x16/:/opt/kde/share/icons/locolor/16x16/
DestroyMenu kde-sys
AddToMenu kde-sys DynamicPopupAction PipeRead 'fvwm-menu-desktop --desktop kde-sys --lang ar --enable-mini-icons --mini-icons-path apps'

Then, "Menu kde-sys" gives me an Arabic KDE3 menu which seems
good (however, Arabic characters are separated and not ligatured,
is this fvwm fault?).

What's may happen on your system is that bidi conversion is
not applied because your font name does not say to fvwm that
the font is an iso10646-1 font.

Nadim, can you test a "today" snapshot when you have time (really
not urgent).

> BTW, couldn't

For portability reason I prefer to use iconv only if there are no
other choice.

> > [snip]
> the charsets to display within fvwm, right ?

Yes and no. The most important thing is that using the good locale
allows to use the Xmb* X functions which do a lot of conversion work
for fvwm. Here an example among others:

With an utf8 locale if we want to display an utf8 string we just
have to call XmbDrawString.
Without an utf8 locale we first have to convert the utf8 string into
USC-4 encoding (not so difficult) and then use XDrawString16.
This is not so difficult (as we know that the string is in utf8),
but we should do an other conversion for JIS encoding, GB encoding,
...etc. As with Xmb* functions conversion are handled by X.
There are other important issues with window names.

> What will a person

The xlfd say that this can be done by the user:

Style * Font -blabla-*-iso10646-1[characters_that_the_users_want]

see the xlfd X doc for more details. Unfortunately, the doc does
not claim that only the "characters_that_the_users_want" must be
loaded and it seems that this does not work with fvwm ...

>   Style * Charset english:arabic:sv.UTF-8:iso8859-7

Yep this can be an idea. however, as Mikhael says that leads to
duplications. What we can do is to extend a bit font name as

MenuStyle * Font -misc-fixed-*-full10x20-1/iso10646-1

i.e., if the font name does not use a standard charset/encoding
the encoding can be added after the font name and after a "/"
separator. Other info can be given:

 font_name/encoding[/iconv_name[/mb_info]]

where encoding is a standard encoding (supported by fvwm) and
iconv_name is the encoding for the system iconv implementation
(there are no standard here). Maybe some multibyte font info
maybe needed in a near future (specially for Xft font).
The advantage of this method is that we do not need to add new
config command (for fvwm and all the modules that load font),
we keep the idea that font define the encoding and that in most
situation nothing special should be added to a config file.
I propose the / for separation as ",", ";" and ":" are already
used in font name but any suggestion is welcome.

Olivier

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 29 Apr 2002 17:43:50 +0200

> Nadim, can you test a "today" snapshot when you have time (really

Ooops, with the today snap fvwm will probably core dump with
certain fonts ...

Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 29 Apr 2002 16:02:43 +0000

> good (however, Arabic characters are separated and not ligatured,

I did the same test with KDE 2.2 with your yesterday's commit (it does not
work without it) using C locale.

It seems that KDE 2.2 was not translated to Arabic, so no results here.
Russian - fully works, French - minor problems, Hebrew - minor problems.
All problems are KDE-specific, not FVWM. For example, they use 'é' (which
is not how it should be written in utf8) in all Programmes submenus, so
entries look like "Syst*", Multim*ia" etc, other submenus are good. And
they use visual Hebrew, so together with Bidi it becomes logical (i.e.
reversed). I hope that KDE 3.0 has logical Hebrew and Arabic.

> used in font name but any suggestion is welcome.

I think it is good. This is needed anyway for unicode that has more than
one encoding, i.e. utf16 and so on.

And I think we should support also specifying an encoding with the string
itself (this overrides the default encoding used from fonts). I suppose
this should work already when XbmString* functions are used; an encoding
may be specified using escape sequences (would be nice to have any spec
about this).

Nice work, Olivier. We have a nice internationalization.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 30 Apr 2002 00:29:47 +0200

> reversed). I hope that KDE 3.0 has logical Hebrew and Arabic.

Here 3 screenshots with the KDE-3.0 head menu. The hebrew and arabic
screenshot are done with  Mark Leisher ClearlyU fonts (Roman Czyborra
has also done Unicode font which cover a very large part of the
unicode). The Japanese menu is done with the Bitstream Cyberbit ttf
which contains a big part of the unicode (Roman, Cyrillic, Greek,
Hebrew, Arabic, Chinese, Korean, Japanese ...etc!!). 
Mikhael is the hebrew menu ok?
Nadim is the arabic menu ok?
Can some one can comment on the Japanese menu?

Olivier

---

From: Nadim Shaikli <[email-masked]>
Date: Mon, 29 Apr 2002 16:00:43 -0700 (PDT)

> Can some one can comment on the Japanese menu?

Arabic looks fine.  The reason it might look "odd" or incomplete
is because Arabic now needs what's termed 'shaping' to join
the characters, but its nothing that you should concern yourself
with (unless you are really interested :-).  I'll take a look
into adding the shaping code to fvwm once I have some time.

BTW: for what it's worth - fribidi will include a library call to
     do the shaping for us; on second thought, let me double-check
     with them on a release date before I start adding potentially
     redundant code.

I'll download tomorrow's fvwm-snapshot to confirm usage :-)

Thanks for all your help !!!

 - Nadim

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 29 Apr 2002 23:16:30 +0000

> unicode). The Japanese menu is done with the Bitstream Cyberbit ttf

Olivier, when you have some time can you please document these tips in
docs/i18n or docs/TrueTypeFonts whatever is more appropriated.

> Mikhael is the hebrew menu ok?

Yes, it seems like KDE 3.0 added Bidi support, so uses logical order.

Regards,
Mikhael.