If Appearence -- Output -- UTF-8 is checked, the main output window works in unicode, input in win1250 - it's a bit annoying, but isn't as bad, as MXP hint, context menu and send all staying in windows code page! Is there any possibility to fix this problem?
UTF-8
Posted by Erendir on Wed 24 Jun 2009 08:36 PM — 9 posts, 34,753 views.
Problem is, MUSHclient isn't a Unicode application.
I tried a while ago to convert, and gave up after hours of code changes, each one spawning off 5 more side-effects.
Thus when it starts, Windows assigns non-Unicode edit boxes, menus etc. as its controls.
The output window can show Unicode because it is a custom drawn window, and I can use the Unicode text-output function calls.
See this post:
http://www.gammon.com.au/forum/bbshowpost.php?id=2681
There are pages of it, and in that I discuss the various things I tried to do to get it to work better.
I tried a while ago to convert, and gave up after hours of code changes, each one spawning off 5 more side-effects.
Thus when it starts, Windows assigns non-Unicode edit boxes, menus etc. as its controls.
The output window can show Unicode because it is a custom drawn window, and I can use the Unicode text-output function calls.
See this post:
http://www.gammon.com.au/forum/bbshowpost.php?id=2681
There are pages of it, and in that I discuss the various things I tried to do to get it to work better.
hm, ok, there are really PAGES, and i really understand, it's not easy to convert the whole application to unicode.
But what is with popup-miniwindow? is it not a it a custom drawn window, so You can use the Unicode text-output function calls?
A workaround would be a conversion of all received MXP TAGs from Unicode to win1250 or whatever. Ok, here's the codepages-problem, but there can be a menu allowing the user to choose, in what cp UTF should be converted.
But what is with popup-miniwindow? is it not a it a custom drawn window, so You can use the Unicode text-output function calls?
A workaround would be a conversion of all received MXP TAGs from Unicode to win1250 or whatever. Ok, here's the codepages-problem, but there can be a menu allowing the user to choose, in what cp UTF should be converted.
The MXP hints are a Windows control, which I don't draw (I just supply the text).
However if you want to use miniwindows these support UTF-8 optionally when outputting text.
However if you want to use miniwindows these support UTF-8 optionally when outputting text.
oh, i thought in 4.41 there're miniwindows used to show tooltips. If not, the simplest way is to convert received MXP into win1250.
Why 1250 in particular? Why not 1251?
In any case, let me see if I have the problem straight ...
If a MUD is sending UTF-8, MUSHclient will display it correctly in the output window, if the UTF-8 flag is checked in the output window configuration. However, if you are using MXP, and the MXP contains UTF-8, in particular in hints shown as tooltip text, then since that is not converted tooltips with UTF-8 codes in them will look like rubbish. For example:
What you are saying, I think, is that if the UTF-8 code for the above arrives (actually 0xC5 0x99), you want that converted back to 0xF8 rather than seeing the 0xC5 followed by the 0x99 in the tooltip.
Is that correct?
In any case, let me see if I have the problem straight ...
If a MUD is sending UTF-8, MUSHclient will display it correctly in the output window, if the UTF-8 flag is checked in the output window configuration. However, if you are using MXP, and the MXP contains UTF-8, in particular in hints shown as tooltip text, then since that is not converted tooltips with UTF-8 codes in them will look like rubbish. For example:
0xF8 0x0159 #LATIN SMALL LETTER R WITH CARON
What you are saying, I think, is that if the UTF-8 code for the above arrives (actually 0xC5 0x99), you want that converted back to 0xF8 rather than seeing the 0xC5 followed by the 0x99 in the tooltip.
Is that correct?
>Why 1250 in particular? Why not 1251?
I thought for some reason, win1250 is the "usual" english win-codepage, and 1251 is a kyllilic one
>Is that correct?
yes, it is.
The problem is, of cause, the user have to choose in some way the language for the encoding function. I have an encoding module, that does conversion between different kyrillic codepages, inclusive win1251 <-> UTF-8
I thought for some reason, win1250 is the "usual" english win-codepage, and 1251 is a kyllilic one
>Is that correct?
yes, it is.
The problem is, of cause, the user have to choose in some way the language for the encoding function. I have an encoding module, that does conversion between different kyrillic codepages, inclusive win1251 <-> UTF-8
Well, I mention it because I don't really see the point of using UTF-8 if you are sticking to the standard character set (win1250). I am presuming that people who want to use Unicode want to render Greek / Russian / Japanese / Chinese (or whatever), and thus putting the tooltips into the 1250 code page may only substitute one problem for another one.
Maybe if the tooltips were rendered in the default codepage for that user (if I can work out what that is), then it might possibly all work out OK.
Maybe if the tooltips were rendered in the default codepage for that user (if I can work out what that is), then it might possibly all work out OK.
>Maybe if the tooltips were rendered in the default codepage for that user (if I can work out what that is), then it might possibly all work out OK.
I think tooltips and context menu are both using 1-byte pro character strings. You can test it by receiving from MUD following:
(with 0xC5 0x99 substituted with the characters with this ASCII codes, of cause)
You'll see a 2-characters tooltip, and with right-click you'll see a context menu again this 2 characters.
I think tooltips and context menu are both using 1-byte pro character strings. You can test it by receiving from MUD following:
<send href="#LATIN SMALL LETTER R WITH CARON|0xC5 0x99" hint="0xC5 0x99">
(with 0xC5 0x99 substituted with the characters with this ASCII codes, of cause)
You'll see a 2-characters tooltip, and with right-click you'll see a context menu again this 2 characters.