Translating command line strings into target charset

My friend, who owns a Garmin GPSMap 60CSx, notified me of a character set problem in a tile name of my map. I wasn't aware of the problem, because my Edge 705 does not display map tile names. The tile Etelä-Suomi (Southern Finland) appears as Etelä-Suomi, where the currency symbol ¤ is displayed as a black diamond. Other ä characters in the gmapsupp.img are encoded as the byte code 304 in octal notation. The workaround should be simple: in mkgmap.args, write the ä as \304 instead of using UTF-8. But I would except the parameter to be translated. After all, the style files are already interpreted as UTF-8. I think that the right fix of this bug would be such that \u escape codes are expanded before utf-8 to target character set translation, and hex and octal escape codes (\xC4, \304) are expanded after the translation. That would also allow us to embed Garmin control characters where desired. Also, I would like to have some transliteration in the UTF-8 to cp1252 (latin1) translation. The Garmin displays many latin1 and cp1252 code points as a black diamond, as I posted some time ago. We could avoid that by translating those code points. I attempted to override the built-in translation (in the JRE as far as I understood) some time ago, but I must have patched the wrong place, because my changes had no effect. Any hints, Steve? Regards, Marko

Hi I know it was quite a while back when you posted this, sorry. On 24/06/09 21:56, Marko Mäkelä wrote:
My friend, who owns a Garmin GPSMap 60CSx, notified me of a character set problem in a tile name of my map. I wasn't aware of the problem, because my Edge 705 does not display map tile names. The tile Etelä-Suomi (Southern Finland) appears as Etelä-Suomi, where the currency symbol ¤ is displayed as a black diamond. Other ä characters in the gmapsupp.img are encoded as the byte code 304 in octal notation.
Yes it just slaps in the string directly without translation. It appears from your example that it is being displayed as a latin1 character set. I don't know what controls that though; does it take the character set from the LBL section or is there something else. A safe first step would be to transliterate to ascii which works over the widest range of languages in mkgmap. ..Steve
participants (2)
-
Marko Mäkelä
-
Steve Ratcliffe