I think it's wise for slackware to not have utf8 set as the default encoding because the installer does not guarantee utf8 support to be installed.

I was very lazy in migrating to utf8. Some important programs, such as xfig, still work better in GBK environment than in utf8. But I had no other choice when I started to face the CJK complexity, then cyrillic and european characters. Although GB18030 is a unicode encoding, most programs work better in utf8 than in GB18030.

As I supposed GNU FreeFont 20120503 causes the similar though not the same problems with my laser printer as the previous version of these fonts.

Today I tested FreeSerif, FreeSans, and FreeMono typefaces in Regular, Bold, Italic, and BoldItalic shapes using the following character set including Polish and French glyphs:

I printed these sets of characters using Brother HL-5340D printer working with PPD file downloaded from the Brother website.

With old GNU FreeFont 20100919 that printer produces the invalid results for the following glyphs:

FreeSerif:
Regular: ĆŃÓŚŹćńóśź ÉÀÈÙËÏÜéàèùëü
Bold: none
Italic: ÀÙÏÜàèùü
BoldItalic: ËÏÜü

FreeSans:
Regular: ĆŃÓŚŹćńóśź ÉÀÈÙËÏÜéàèùëü
Bold: ËÏÜëü
Italic: ĆŃÓŚŹćńóśź ÉÀÈÙËÏÜéàèùëü
BoldItalic: ĆŃÓŹćńóź ÉËÏÜéëü

FreeMono:
Regular: ĆŃÓŚŹ ÉÀÈÙ
Bold: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù
Italic: none
BoldItalic: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù

With old GNU FreeFont 20100919 repaired automatically using the method mentioned in post #14 that printer produces the invalid results for the following glyphs:

FreeSerif:
Regular: ÏÜü
Bold: none
Italic: ÏÜü
BoldItalic: ÏÜü

FreeSans:
Regular: ÏÜü
Bold: ÏÜü
Italic: ÏÜü
BoldItalic: ÏÜü

FreeMono:
Regular: ÏÜ
Bold: ÏÜ
Italic: ÏÜ
BoldItalic: none

With new GNU FreeFont 20120503 that printer produces the invalid results for the following glyphs:

FreeSerif:
Regular: ËÏÜëü
Bold: none
Italic: ËÏÜëü
BoldItalic: ËÏÜëü

FreeSans:
Regular: ËÏÜëü
Bold: ËÏÜëü
Italic: ËÏÜëü
BoldItalic: ËÏÜëü

FreeMono:
Regular: ĆŃÓŚŹ ÉÀÈÙ
Bold: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù
Italic: none
BoldItalic: ĆŃÓŚŹćńóśź ÉÀÈÙéàèù

As you see many glyphs are repaired in those fonts since version 20100919.

I didn’t test my method of repairing the glyphs with the new GNU FreeFont 20120503 yet so I can’t guarantee the results will be the same as with the previous version of these fonts.

Yes. I have encountered no problems with UTF-8.

Well, it doesn't need it. Even when you use an UTF-8 locale, you can set it to "C" or "POSIX" in your scripts to stick them with ASCII (it is even advised if you don't want they break due to some localization issue).

Personnaly, I was a bit like you, seeing no urgency to migrate. I did it when I tryed git for a private project where the logs were in French (git uses UTF-8 as default, you can choose another encoding, but there's then no way to change it in the future of the project). I finally abandoned git, but UTF-8 remained. Of course I won't go back, but I continue to think iso-8859-15, while not being as perfect as UTF-8, allows to write a very decent French.

I like text files and have many of them, so the migration was a bit tricky. Plus, I was then a bit new to this kind of issues. The main gain was with LateX or HTML: no more need to escape all special characters. Regarding to the inconvenients, very few: things like xdvi or xmessage are slowed (they take several seconds before starting), and there's of course some mess with the manuals. For xmessage, I use it rarely but set it in locale C to fix the problem. For xdvi, I stopped to use it to produce PDF exclusively (it's the same printing-wise, and PDF is in all the cases better to share documents). For the manuals, I found no magic solution, but I however prefer to refer to the English man-pages which are generally the most up-to-date.

@Didier Spaier: De rien (you're welcome)! ;)

installed terminus font and have in rc.font
unicode_start ter-v16n
gives a nice terminal font an no problems since many years

Unfortunately not all of the programs in the system is written by me. So I can't do it actually.

Yes, I was speaking only of the installer, which could stick with ASCII without impacting the charset of the default system as long as it is needed. Regarding to the system, which programs cause you trouble with UTF-8?

Xfig for example. I had various problems with it since I migrated from GBK to UTF-8. In the end I decided to alias xfig to "LC_CTYPE=C xfig". A similar example is mathematica.

I also have to remove the localized man pages of the shadow package, etc. because they can't be displayed properly. Yes I know there are solutions but I'm too lazy to apply them and I'm not wishing to see these few localized man pages anyway.

There are other problems. But I can live with these. On the other hand, I cannot live with improperly displayed Japanese, Russian, and German strings under GBK. Nor can I accept the GB18030, though it's unicode, because too many things are broken under GB18030, including scim, which is essential to me.

I use UTF-8 because I need to be able to display Japanese characters, and input them using scim/anthy (actually since Slack 14 I've been using iBus and anthy). I've had difficulty getting KDE to display kana so setting the locale to UTF-8 is one of the first things I do on a new install.

I'm actually having terminal/font display issues when using regular Terminal in KDE. I get odd text artifacts in sbo, among other things. Funny thing tho, if I use Konsole for my terminal, there are no problems (as of yet).

Yes -- because I'm internationally friendly and up-to-date sort of guy. And Bacula wants it which stopped me dithering way back when.

Actually the answer should be "maybe" rather than "yes". Is it an installation time option? My 14.0 OS installation log has no mention of it. I manually changed /etc/profile.d/lang.sh to have these two effective lines ...
... and use kernel parameter vt.default_utf8=0 (forgotten why, it disables UTF-8 on the virtual terminals).

I have it set to use it simply because I like to see foreign (to me) words the way they're *supposed* to look if I happen to go to a website or whatever.

AFAIK I've not had any problems because of it, *unless* it's what makes everything look like a garbled mess if I restart the system in init 3 (so I can use mc, for instance). Nothing can be read, but as I fiddle my way around in mc, things will sort of clear up where the cursor line is once I type or something (I hope that makes sense).

If it is because of the UTF8 thing, well, so long as I can still figure my way around at the prompt I'll leave it be.

irgunII,

1) Edit your /etc/lilo/conf, replace:

with:

and rerun lilo command.

2) Edit your /etc/rc.d/rc.font and put there the line:

After reboot everything should work well.

(Midnight Commander in the mode you described looks and works horrible.)

NonNonBa,

Over 1000 views and below 100 votes in your poll. Is it so hard to press the [Vote Now] button?

Maybe 900 of them aren't slackware users and they were just being nosey to see what we were talking about. ;)

Or maybe they simply do not know the answer because:
(1) They do not remember if/how they set up the character encoding at time of installation.
(2) They do not know what UTF-8 means/is.
(3) They do not know what a character encoding is or that there are several ways to encode a character or that several character encodings are available in Slackware.
(4) They visit any new thread in this forum, just in case they would find something interesting for them or someone they could help.
(5) Another reason I can't think of right now.

Maybe we should setup another poll to find out to which categories readers of this forum fall into?

PS. About categories, I can't refrain to quote the late Ann Landers: