Line wrapping is now broken in mIRC when dealing with lines encoded in UTF-8..

Steps to reproduce: Clean install of mIRC 6.32 on a Western European Windows. Enabled multibyte display in the options and set UTF-8 to display & encode in the channel settings. Copy & pasted a line of text from the Japanese Wikipedia. As long as the text fits in one line, it looks ok:



But when I make the window a bit smaller:



Expected result: the line should wrap without breaking ;-) It works fine in 6.31.

Other info: toggling Multibyte display doesn't change anything.

Just installed 6.32 and got the same problem, it fails where 6.31 worked.

As in 6.31 changing the width of the window alter the visualization of the characters but there is still no way to have all them displayed correctly and even if sometimes the characters on the last line are displayed correctly the overall situation is worse (whereas in 6.31 it usually worked for the first few lines and then it fails on the others).
The "Fixed multi-byte text-wrapping display issues." doesn't seem to work.

If you need some screenshots and/or more infos let me know, I'm running win xp sp2.

If you want to test it you can find here http://dpaste.com/52723/ 3 lines with the hiragana, katakana, greek and coptic characters that are displayed correctly on 6.31 and as a list of "ã", squares and some other characters in 6.32.

I advantage of this topic to report another UTF-8 bug.
Today I noticed that if I write an Asiatic character and add the char « » the conversion not appear... like in the image (I use a my own skin engine)

That's because the ANSI encoding of those characters is invalid UTF-8, so when mIRC sees them it assumes that the rest of the line isn't UTF-8 either. To fix this you should use the $utfencode() identifier around the guillemets (the « » characters).

$utfencode is not necessarily a fix, see the original posting of this issue here:

https://forums.mirc.com/ubbthreads.php?ubb=showflat&Number=196819

There is no workaround to this issue, currently.

Thanks this has been fixed - I plan to release a new version with this issue fixed as soon as the handful of other outstanding issues are resolved.