Hi all,
I am a an application programmer ,currently working on GUI(linux).
I am using arm processor
Processor : Intel XScale-PXA255 rev 6 (v5l)

and...

Linux version 2.4.18_mvl30-dbpxa250 (hw@pc031) (gcc version 2.95.3 20010315 (release/MontaVista))

I just want to know what is the best GUI toolkit available which support Internationalization in such a memory constraints
Only condition is, it should be light and fast .

I tried with fltk118-utf8-2007-07-14 which provide the patch for Internationalization ...It runs good in other processors (eg:-Intel(R) Pentium(R) 4 CPU 2.66GHz ,Windows)but not working with my arm processor (Intel XScale-PXA255 rev 6 (v5l))(


Can anyone help me in this ...

Thanks in Advance

It may just not work well with that kernel: 2.4.18 is quite old.
I see you are using MontaVista Linux... ??
I see the example of a system your package works on is a windows system.

Hi,

Thanks for you valuable reply
I tried running the same fltk118-utf8-2007-07-14 version in my machine with

• Linux version 2.4.20-8 (bhcompile@porky.devel.redhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5))
  
• Intel(R) Pentium(R) 4 CPU 2.66GHz

It is working properly ,showing fonts (though some are missing there also )
like arabic,german etc... but in windows it is working perfect

What might be the reason ?

I tried down loading some of the fonts http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
and followed the follwing instruction which I found in manual page of X

Still I am not getting proper font


That's the reason I thought that fltk not at all supports Internationalization in arm processor(Processor : Intel XScale-PXA255 rev 6 (v5l)) I may be wrong but I don't know the way actually to come out of it

Please help me out of this mess

Or can you tell me the best GUI toolkit with Internationalization support in arm processor(Processor : Intel XScale-PXA255 rev 6 (v5l)).

linux internationalization is handled differently from windows, so the package will be quite different. You need to install "locales" as well as the fonts. You will find that many fonts in linux include international characters in the same font.
Do I understand this to be Red Hat Linux 9 ?!?

If you will insist on using severely depreciated distros, you can expect trouble like this. Look at the difference going two release levels (2.4.18 --> 2.4.20) made - imagine the difference 15 levels make! (www.kernel.org says we are at 2.4.35)

But it's not just that, everything is done differently now. RH9 stopped being supported by 2003 (someone correct me) and fedora 8 (RH17!) is in the pipeline. Do yourself a favor and update your systems.

I'm running Kubuntu Gutsy Gibbon and I have the locales package installed. The file listings shown by Konqueror do display international characters correctly, but those shown by amarok do not. Both of them are using Sans Serif 9. What do I need to do to display the international characters in amarok? And how can I tell if a font provides international characters -- or do they all?

All unicode fonts are capable of internationalization. However, the standard is not fully implimented outside of latin fonts. The only sure way to know is to apen the font in a character-map tool and look. If you are used to the old ascii/ansi standards, you'll be amazed at how many characters there are.


"Sans Serif" is not a font but a style - a "serif" is the little caps you get on the end of long lines in a letter like in the Times Roman font. If you want to see the difference, have a look at the Bitstream Vera fonts in a wysiwyg word processor.

However - "sans serif", "mono" etc are also used as labels for default fonts. You probably need to change the font amarok uses to something like "Bistream Vera Sans" explicitly. It is possible that the default sans font doesn't have all the characters you want and other apps are getting them from another font. Or it could be that amarok dosn't support non-latin characters.

The "9" in the name is the point-size of the font, and not a version number... in case you were wondering.

Just to be sure, I took your suggestion and set the font to Bitstream Vera Sans (9 pt) and then went into Office Writer and typed some international characters using the Compose (Menu, actually) key. They showed up just fine. Same thing happens in the amarok search window (as it should). But still the titles of tracks and albums show up with weird characters like à followed by the 1/4 character. And this happens from albums from a number of different sources, so it's not just one person's encoding. I think these titles are actually encoded on the CDs that I've been ripping.

I thought that maybe by fiddling with display fonts I could get these weird characters to show up as the characters they are intended to be, but maybe not. I have no way, other than looking at the amarok collections, to examine what's been transcribed from the CDs.

Probably those titles were not unicode. There's no reason CD vendors should all agree to use the same standard. They may be anything from ansi to some variation on ISO.

Usually, you can get proper rendering with the US English... unless these are non-"international" titles. This is the sort of thing unicode was invented for - but not everyone uses it all the time. Remember, all recording companies care about is that it works on standard HW CD-players.