Hello. I thought this would be simple to solve but I've taken a look around and can't figure it out.

In my xmms playlists, song titles with foreign language/international characters display with those characters simply removed. Specifically, accented spanish vowels that display in a terminal window as "\202" or something like that aren't shown in the playlist. I'm trying to figure out what I need to do to get these to display properly. Thanks in advance.

I'm not sure about that, but i think this has to be with the codification of your system.
Try to edit /etc/sysconfig/i18n file (at least on FC2 is there) and under supported add "es_ES@euro"
If does not work, try to put it under LANG, the codification will be the same as plain english plus accents and so on.

Hope this helps

Hmm, that's not there on Slackware. Your post did make me think of something though... is this the normal way that Linux expresses foreign language characters? These songs were ripped originally under Windows, and I'm just wondering if those escape codes are what are throwing it off.

AFAIK yes, i had similar problems with irssi (irc client), i couldn't use accented vowels and some special characters like "ç", and either displayed correctly when someone else typed them, so i had to change and add that es_ES@euro on that file.

Although the location of the file is not the same, the file itself should be the same, try a locate on i18n and see.

In the XMMS Preferences window, Fonts tab, you must select fonts that have the characters you wish to see. If you play files whose names are encoded in UTF8 (Unicode), you should also put a tick in the "Use fontsets" box. These measures don't cover the whole program - some i18n work remains to be done.

The /etc/sysconfig/i18n file is a settings file mainly for the shell (and textmode programs). If the shell shows funky escape sequences in place of non-ASCII characters, it may not support or isn't set up to support the character encoding that is used.

Many people still use language and country specific encodings instead of UTF8 in IRC. It's a pity, since Unicode is a much more advanced system, but both practices have their advantages.

Regards
Simon

This is turning out to be much harder than I thought. Is there any way to figure out what fonts support these characters? Also, I found the i18n file but don't see a "supported" section there.

I would recommend trying. Tinker with the options until you get what you want or at least are satisfied with. There are programs for browsing and listing fonts installed on your system: kcharselect, gcharmap, xfontsel, xlsfonts (and probably others).

You can add it there. Here's what the file might look like:

LANG="en_GB.UTF-8"
SUPPORTED="en_GB.UTF-8:en_GB:en_US.UTF-8:en_US:en"
SYSFONT="latarcyrheb-sun16"

Simon

Ok. I used kcharselect to browse the fonts and saw that the default one being used in xmms did have the characters I want to display. Are you saying that the i18n changes must be done to get even the playlist to show those symbols correctly, or that that just covers the rest of the program? I tried several different fonts and none worked, even though those fonts had those characters.

I'm saying that the playlist and main window work fine when I tune the font settings, but the title bar (with WM decorations on), for example, doesn't. We must wait for future versions.

Try disabling the Use fontsets option. If the filenames are in Latin-1 (ISO-8859-1) or Windows-1252 encoding, the accented characters don't show at all if XMMS treats them as UTF-8. If the situation were the other way around, you should see some garbage instead of no characters.

When you click the Browse buttons in the Fonts tab you get the font selection window. There's a scroll box named Font Style. There you can select italic and bold fonts, but also different encoding tables the font might have. This could make a difference if you're trying some weird fonts.

Also make sure you are running XMMS version 1.2.10 (the latest one).

Simon

I'm using XMMS 1.2.8, but would that small of a version change make a big difference here? I tried disabling that Use fontsets, removing all the entries, and adding them again, but the letters still didn't appear. I'm not trying any weird fonts... just the normal (and default) ones. Any other ideas?

Possibly yes, but probably not.

This sounds more of a problem with your window manager, X server or font server. Are you able to view the characters in other GUI applications, like text editors and file managers? Give us examples. OpenOffice.org apparently uses its own font drawing mechanism, so it's not relevant here. Did you follow Hammett's advice?

Simon

I didn't make changes to the i18n file yet since it sounded from what you said that it wasn't required to make just the playlist display properly (and that only the fonts were at fault). I'm also not familiar with that file and what the options do (what my current setting is, needing to support unicode or not and the results of changing that, etc.), so if that's the next step I need to take it'll require a bit of research before I do anything.

As far as how other applications work, the first thing I noticed was in a terminal. I've set up my system to be able to type these characters, and I can type them on the command line, but the resulting message or file created uses escape codes instead of the letter. I just realized these escape codes differ. For example, if I search for a file including "Café" (typed with that character on the command line), I get "/usr/bin/ls: *Caf\351: No such file or directory." However, when I "ls *Caf*" I get "Bass'n\ Helen\ -\ Caf\202.ogg*" (with 202 instead of 351). Any idea why what I'm typing is one code and the file itself is another? In other applications (text editors) I can obviously see the characters if I type them, but if I try to open a file and browse to that directory, it still doesn't work. In gedit, for example, the files with those characters do not display at all in the file list. Gimp shows those files, but with a box instead of the characters. Does this help narrow it down? Do I need to make the i18n changes? Thanks again for your help so far.

After reading this thread, I do not have any idea on fixing the problem.

see the bottom-right part of link below.
http://www.cs.hku.hk/~ttwong/snapshot.png

Segmentation fault of XMMS! (after clicking fontset option)

I wonder XMMS that comes up with slackware does not support multi-languages.

Okay, I checked what the /etc/sysconfig/i18n file is. The shell start-up scripts on Fedora Core are set so that they source the i18n file, that is, they execute commands in it. Apparently also graphical programs and X itself depend on the LANG variable set in it, and perhaps the SUPPORTED variable too. I believe it's quite possible to compile common programs with i18n support turned off, though, and it's hard to make it perfect.

The escape code \351 is in octal notation. It corresponds to the small e with acute. \202 is more mysterious, as it isn't a printable character in Latin-1.

At least the LANG or, if it's not enough, the LC_ALL variable should be set correctly eg. in /etc/profile, ~/.bash_profile or /etc/profile.d/lang.sh (if you're using Bash). SUPPORTED probably adds support for additional encodings. You can get some info about current settings by typing locale. Desktop environments have their own locale setting facilities but I'm not sure how they work in relation to the shell variables. Kaon should also try updating the system's font packages if there's fixes available.

But before you do anything, consult the wonderful search feature of this site. Here's some more help on the matter:

http://www.linuxquestions.org/questions/history/208775
http://www.linuxquestions.org/questions/history/193229

Simon

EDIT: In case someone reading this wonders what "i18n" means: it's just computer slang for internationalization (i + 18 letters + n).

well, i have to say that i too have a problem with non-US characters (i don't know, i think they're Greek). anyway, i've got suse 9.1 personal and i've searched on google and on this forum for the problem. i fixed a bit of it. here's how it goes: i read an m3u generated by winamp with songs that contain these characters (the mp3 names and tags are the same). at first xmms (1.2.10 in case you need to know) didn't show them. but i fixed it by selecting other fonts in its options. but it still can't read them because the link it enters in the playlist is WITHOUT those characters (i just open the m3u). so where do i have to setup the font used because i CAN load the files separately and i can't see all the fonts that xmms can use in Kwrite. i'm thinking xmms must use an intermediate which reads the m3u and that intermediate doesn't know these characters.

sorry i didn't post a new topic but it seemed appropriate to use this one