MegaGlest Forum
Archives (read only) => Glest Advanced Engine => Bug reports => Topic started by: John.d.h on 15 April 2011, 10:27:35
-
The recent revisions to the GUI look fantastic and things seem to be running more smoothly for me, but here are a few little hiccups I've noticed:
Just another place where the diacritics aren't working:
(http://img703.imageshack.us/img703/3883/screenshotrr.th.jpg) (http://img703.imageshack.us/i/screenshotrr.jpg/)
(Should be Leñadores)
And the orange down arrow seems to be missing.
(http://img829.imageshack.us/img829/1607/screenshot2ex.th.jpg) (http://img829.imageshack.us/i/screenshot2ex.jpg/)
(http://img810.imageshack.us/img810/3346/screenshot1gn.th.jpg) (http://img810.imageshack.us/i/screenshot1gn.jpg/)
-
Picture at top has lang file encoded in ansi , second is in utf.
(http://i687.photobucket.com/albums/vv231/silnarm/glest/Leadores.jpg)
-
No repair speed
(http://img200.imageshack.us/img200/5759/screenshot1dj.th.jpg) (http://img200.imageshack.us/i/screenshot1dj.jpg/)
Leñadores went blank
(http://img853.imageshack.us/img853/5804/screenshotdn.th.jpg) (http://img853.imageshack.us/i/screenshotdn.jpg/)
-
If the diatric is outside of the [extended] ASCII range (0-255) it gets read/stored as negative (or at least the ones I saw are). This means that when it comes time to get the width for the character in FontMetrics::getTextDiminsions it throws off the x position with an invalid value ( m_pos = {x=-1073741681 y=3 w=-1073741681 ...} ).
width += widths[str[i]];[6] = -31 'á'
[2] = -15 'ñ'
Although "Leñadores" works for me but "CPU (Fácil)" doesn't.
-
How would we fix it? Would using UTF-8 encoding solve the problem?
-
How would we fix it? Would using UTF-8 encoding solve the problem?
Shocking if the system isn't utf-8 already wouldn't you say?
-
How would we fix it? Would using UTF-8 encoding solve the problem?
The problem was actually a little different to what I thought. The reason why it was negative was because it was stored as a char in a string which goes -128 to 127 so any of the extended characters, above 127, were becoming negative. It is now casted to unsigned char (0 to 255) in that place and it works.
-
it works.
Does it?
(http://img155.imageshack.us/img155/2326/screenshot3xy.png)
-
it works.
Does it?
Yep ;) The FontMetrics are correct now, everything is nicely centred, nothing has been pushed off the screen by dodgy indexing into the character widths array (the negative numbers hailstone mentioned).
Save that file as ascii, not utf!
-
Oh... right... how do I do that? :look:
-
Depends... your favourite text editor may have an encoding menu, or encoding as a submenu of some other menu... or it might be an option on the save dialog (try save as..). Or of course it may not have it anywhere... most would these days though, at least you would think.
Last resort, there is GNU 'recode'.
-
In Notepad++:
Encoding > Encode in ANSI
-
Awesome! ;D
It turns out that gedit doesn't do ANSI, so I'm running Notepad++ on WINE, and that converts it just fine. I've pushed the recoded Magitech language files, so I guess that means this problem is fixed. :)
-
Awesome! ;D
It turns out that gedit doesn't do ANSI, so I'm running Notepad++ on WINE, and that converts it just fine. I've pushed the recoded Magitech language files, so I guess that means this problem is fixed. :)
You know, Notepad++ is open source, you could just compile it for linux and experience the awesomeness. :thumbup:
-
You know, Notepad++ is open source, you could just compile it for linux and experience the awesomeness. :thumbup:
No can do. It uses Windows-specific libraries. :( It runs flawlessly on WINE as far as I can tell, though.
-
You know, Notepad++ is open source, you could just compile it for linux and experience the awesomeness. :thumbup:
No can do. It uses Windows-specific libraries. :( It runs flawlessly on WINE as far as I can tell, though.
Really? My bad, sorry.
-
vim can change file encoding (emacs should be able to as well). http://stackoverflow.com/questions/778069/how-can-i-change-a-files-encoding-with-vim