On Fri, Apr 26, 2002 at 06:07:37PM -0700, Nadim Shaikli wrote:
> On Thu, 25 Apr 2002 23:26:17 +0200,
>   Olivier Chapuis <olivier chapuis free fr> wrote:
> >
> > On Wed, Apr 24, 2002 at 12:41:38PM -0700, Nadim Shaikli wrote:
> > > On Wed, 24 Apr 2002 06:56:05 +0200,
> > >   "Olivier Chapuis" wrote:
> > > > 
> 
> [snip snip]
> 
> > 
> > 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).
> 
> Just in passing, those fonts are not specific to vim and no special
> 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
> those methods (libiconv and others) be things that could be included
> during configure time ?
>

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

> > [snip]
> 
> > 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 ...).
> 
> 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 ?

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
> 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.
> 

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 ...

> 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.
>

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
--
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