Re: wxWidgets terminal (bug report)

[<tim...@en...>]

> On Saturday 29 April 2006 02:25 pm, you wrote:
>>
>> "As soon as Fontconfig is properly setup, adding fonts is just a matte=
r
>> of
>> placing them into a directory that is searched by Fontconfig. Have a
>> look
>> at /etc/fonts/fonts.conf (and perhaps /etc/fonts/local.conf) to find o=
ut
>> what directories are searched.
>
> Aha. Thanks!
> I did not know about that mechanism at all, and have not
> been using it.  Adding that file makes a lot of difference :-) :-)
> My X11 setup uses a similar mechanism, but does it through
> /etc/X11/fs/config rather than /etc/fonts/fonts.conf
>
> With that file in place, I can now use all the fonts that I
> couldn't get before in wxt.  Including "Wingdings", which I thought you
> had said before was not working.

Hmmm. Interesting. Indeed, Wingdings works for me too. You made me give
another look at the "Symbol font problem", and I finally figure out the
following :

There are two types of Symbol fonts : the Adobe one, and the Microsoft
one. The Microsoft one is likely to use a different mapping than the Adob=
e
one, and the Adobe encoding is the "official". I have a Microsoft symbol
font installed (symbol.ttf in one of the fonts paths). I also had an Adob=
e
one brought by Acrobat Reader, but not in the fontconfig path. Finally I
had the Opensymbol font, brought by Openoffice (and available on several
distributions as a separate package), but again not in the fontconfig
path.

I added the two of them to the fontconfig package, runned 'fc-cache' and
they immediately appeared in all my kde apps ! Fontconfig is great !

However, they still appear with the utf-8 encoding, that is to say that
enhancedtext.dem still won't work without the function that translates th=
e
"Symbol encoding" to the utf-8 encoding.

That means that the system knows that the Symbol encoding is special, and
handle the case separately. After looking a little more, I found the
following file :

/usr/X11R6/lib/X11/fonts/encoding/adobe-symbol.enc.gz

which contains precisely the map from the Symbol characters to Unicode !
That's why the system understands this font as a normal font, after
applying this encoding translation.

So currently the path is the following :

input in Symbol encoding -> translation from Symbol to utf-8 by wxt ->
translation from utf-8 to the custom Symbol encoding by pango/X11 ->
proper rendering in the Symbol font

My layer ("translation to utf-8 by the wxWidgets terminal") is useful to
maintain compatibility with enhancedtext.dem, but will not work if the
user already enters its characters in utf-8 and chooses the Symbol font...
In this case the layer should not be used, and the characters should be
sent directly to pango.

Ouch ! Still have to figure out how to satisfy all cases...

Timoth=E9e