Re: Disabling Pango in GTK

[John K Luebs <jkluebs luebsphoto com>]

On Thu, Mar 06, 2003 at 11:12:19AM -0500, Granitslab wrote:
> Hi, I'm working on a prog for my boss, and thought of GTK+ for my interface.
> it is, basically, a remake of an old DOS facturing application, which source
> code I do not have, to win32
>
> Target language : pure C,
> Target platform : win32 only
> Target language : French
>
> and as soon as I define a label with its text containing accented characters
> (é, À, è, etc.),
> Pango refuses to render it.
> I'd like to be able to use plain ASCII with GTK+, 1) because of this problem
> 2) Because Pango's rendering is very slow. I know x-chat2 uses gtk2, and
> SETting a var in autoexec disables it, but that's not such a nice way,
> especially since this app will be on a server, and accessed by many

Well, strictly speaking, your target language requirement can not be
done with ASCII. ASCII (The A stands for American) is 7 bit and has
no accented characters.

In order to simplify things, GTK+/Pango assumes things are valid UTF-8
throughout. This gives GTK+ full Unicode flexibility in a way that can't
break in the future (like UCS-2 used by Windows).
You are most likely assuming ISO-8859-1, and not getting the
results you desire. You can either manually convert all your strings to
UTF-8 or you can convert your ISO-8859-1 encoded strings to UTF-8
programatically using libiconv. Information on libiconv is available at
http://www.gnu.org/software/libiconv. Note that a standard GTK+ runtime
install on Windows will include libiconv, so this is nothing obscure.

As for Pango slowness. Pango is certainly not the quickest thing
around, and profiling (with GTK X11 only) shows that it does take a
noticeable chunk of time, I haven't found the slowness to be a problem.
Most of GTK and glib have become very efficient, so Pango simply stands
out like a sore thumb. In absolute terms, I haven't found it to be too
bad.
Have you actually found Pango to be slow or have you just heard that it
might be slow.

> Or, maybe, could you point me out to another GUI-making api like GTK+, maybe
> simply restricted to windows, with pure C programmation and
> non-lame-programmation-structure (GTK, for instance, is non-lame. I *might*
> use the win32 api, but I'm kinda afraid that one will be something ugly to
> deal with.)
FLTK is pretty nice, but I don't think it is a GTK competitor at this
point. wxWindows is fundamentally different in that it wraps the native
toolkit, so its functionality is lowest common denominator (a negative)
but it looks just like a native app (a positive most times).
The only comparable rival to GTK+ that I know about is Qt, and that is gonna
cost you on Windows.

I don't think the problem you mentioned is a good reason to give up GTK+
though.