Text POI's with special chars will be incorrect displayed.

[tuxmaster]

Hello when using test files as an map source, the stings are only shown correct at the action->coordinate window. But on on the map self, it will be shown incorrect.

poi file:

mg:13.667568 52.446803 type=poi_custom1 label="Special Char test öäu"

gui: internal graphics: sdl, qt_qpainter or gtk_drawing_area always the same. see the attachment for the output.

[tuxmaster]

The incoreect drawing of the special chars.

[tuxmaster]

The location part, where it will shown correct.

[tryagain]

Hi!

Please try something like <map type="textfile" enabled="yes" charset="utf8" data="map.txt"/>

There's probably a bug in internal gui that allows you to read labels from a misconfigured map. Textfile map defaults to non-unicode charset iso8859-1. But your map file is probably entered in utf8. So properly working code is displaying non-readable labels due to attempt to do cp8859-1->utf8 conversion while it's actually not needed. And gui_internal code lacking conversion works ok.

Not closing the ticket as the bug exists and we should fix it.

tryagain

[tuxmaster]

Yes the text file is utf-8 and adding charset="utf8" to the map entry will work.

Thanks.

[sleske]

Hm, maybe we should just remove the default charset ISO8859-1 and make the "charset" parameter mandatory? Or change the default to UTF-8, and abort if we detect invalid characters?

[tuxmaster]

I think UTF-8 for default will be an good idea, because it will not break anything, because only special char's have two(or more) bytes. As long nobody will use Cyrillic or japanase char's.

[tryagain]

Actually, I plan to switch textfile map to use utf8 by default but also make gui_internal call charset conversion function like it's being called now in label display code.

Otherwise non-unicode text attributes will be broken in gui_internal.

[tryagain]

Hi!

Fixed with ​r5762 ​r5763/ r5763 ​r5764 ​r5765.

Map originated strings are everywhere converted before usage, and csv and textfile maps default to utf-8.

tryagain

[tuxmaster]

Yes I can confirm, it works like expected. Thanks