#1089 option readfile cannot use multibytes

[Eiji Ikeda]

since 'option readfile' doesn't convert encodings
of the target resource file,
multibyte characters in such resource files
(mainly for Japanese TrueType font name on MS-win32)
are not interpretted correctly.

on MS-Win32 environment, I wrote a resource file:

*Label*Font: {Times New Roman} 40 normal

goes well, but when I use Japanese TrueType font
names replacing above 'Times New Roman',
the font is not loaded, and the output of
[.label cget -font] is in some binary(unreadable)
characters.

[Donal K. Fellows]

Logged In: YES
user_id=79902

Hmm. What should be the encoding of an option file anyway?
I don't recall seeing that defined anywhere, but it is quite
possible that it is instead *helpfully* defined (by the X
consortium) to be ISO8859-1... :^(

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

What is the Japanese TT font name being referred to? Which
Win32 platform (Win2K with IME, or ??).

[Eiji Ikeda]

Logged In: YES
user_id=367034

Platform is MS-Windows98 Second Edition. And some
people in Japan also reported so, they use Win98, NT4.0,
and Win2K.
The two very popular Japanese TT-font names are
"ͣӡå"(MS-Gothic) and "ͣӡī"(MS-Mincho).
As well as them, almost all of Japanese TT Font names
on Win32 (and their *.ttf file names) are named
using Japanese multibyte characters.

[Donal K. Fellows]

Logged In: YES
user_id=79902

It seems that the following functions in generic/tkOption.c
are (probably) not i18n-aware:
AddFromString
GetDefaultOptions
ReadOptionFile

There may be other problems through the option code too. I
must admit that I'm not experienced enough with it to say
for sure.

A possible work-around would be to build an option-file
parser in Tcl and use that (plus [option add]) instead of
the C version...