Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ Suggestions
➜ UTF-8
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Erendir
Germany (47 posts) Bio
|
| Date
| Wed 24 Jun 2009 08:36 PM (UTC) |
| Message
| | 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? | | Top |
|
| Posted by
| Nick Gammon
Australia (23,162 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Wed 24 Jun 2009 09:23 PM (UTC) |
| Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Erendir
Germany (47 posts) Bio
|
| Date
| Reply #2 on Wed 24 Jun 2009 09:46 PM (UTC) |
| Message
| 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. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,162 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Wed 24 Jun 2009 10:39 PM (UTC) |
| Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Erendir
Germany (47 posts) Bio
|
| Date
| Reply #4 on Wed 24 Jun 2009 10:47 PM (UTC) |
| Message
| | 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. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,162 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Wed 24 Jun 2009 11:21 PM (UTC) |
| Message
| 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:
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?
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Erendir
Germany (47 posts) Bio
|
| Date
| Reply #6 on Thu 25 Jun 2009 12:47 AM (UTC) |
| Message
| >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
| | Top |
|
| Posted by
| Nick Gammon
Australia (23,162 posts) Bio
Forum Administrator |
| Date
| Reply #7 on Thu 25 Jun 2009 12:56 AM (UTC) |
| Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Erendir
Germany (47 posts) Bio
|
| Date
| Reply #8 on Thu 25 Jun 2009 01:08 AM (UTC) |
| Message
| >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:
<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. | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
28,586 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top