[MPlayer-dev-eng] [PATCH] Use _NET_WM_NAME for UTF-8 title in X11 if supported

[Matthias Hopf]

On Jun 23, 06 11:58:53 -0400, Rich Felker wrote:
> > I don't think locale stuff can be done lightweight, too much stuff to be
> > considered especially for arabian (right-to-left) and eastern (large
> > charsets, combined characters, multiwidth characters) languages.
> 
> None of this requires significant special support by ordinary
> applications. If you don't believe it can be done lightweight then try
> out my 640k DOS UTF-8 terminal emulator with support for all scripts
> once it's released. (Yes the 640k includes all glyphs. :)

Including all >68000 glyphs? That makes less than 10 bytes per glyph,
which would be impressive for a 14 point font ;)
BTW - where did you get all that glyphs from? We are constantly
struggling geting all glyphs in a decent quality font...

> > - not being able to easily(!) switch between POSIX/C style and locale
> 
> Even if you could do this it's still broken, because all it can do is
> make _localized_ applications, not _internationalized_ applications.
> We do not live in a world of isolation anymore. Just because I'm in
> country X does not mean I don't want to be able to process data from
> country Y.

That's why I need something like this. To store data in a format that
can be easily read in another locale. Is this missunderstandable?

> This is what my C library implementation provides, and nothing else.
> UTF-8 will also mostly work with 'ordinary' C locale except that
> character widths and such will be messed up.

... which is irrelevant if the user can only display ASCII anyway.

> > Perhaps I was inserting too little <sarkasm> tags. In fact, I wanted to
> > point out that *printf is perhaps the most important routine to be
> > localized IMHO. You need locale dependent number formating. At least
> > that is what customers say.
> 
> *puke* If this is really needed then all you need is a new format
> specifier, or a separate function printf("%s", local_num(buf, sizeof
> buf, locale, n)); Bloating printf up more and more is the stupid GNU
> approach and it's the reason hello world is 400k with glibc!

I didn't say that the localized version should be named the same. Yes,
renaming it would be a valid approach. I assume that it was considered
that by just changing printf() many programs would automatically output
localized numbers - not realizing, that localization needs support by
the program (gettext etc) anyway...

Just to make sure: I wouldn't call 400k *code* to be lightweight - so
helloworld.c with glibc isn't.

> > maybe with current characterset encoding.
> 
> Idea of current charset is deprecated. Hopefully it will be gone in 5
> years or so..

In a perfect world you would be right.
I don't think we will have e.g. the majority of Japanese people
converted in 5 years :-(

Apple was bold enough to nuke everything non-UTF-8, but I just heard
that in Japan Macintoshs are almost not used for text processing...

Matthias

-- 
Matthias Hopf <mhopf at suse.de>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at mshopf.de
Phone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de