Windows version of internationalization

[jlacroix]

This bug is to make sure the internationalization of mapserver works on windows.
Assefa have begin to test the compilation under windows to make sure everything
works. 

Assefa, can you report your result here, please?

Mario, can you test the binaries Assefa will build to make sure the
internationalization works under windows, please?

[jlacroix]

Assefa,
Note that mario attached a demo that work out-of-the-box in bug 858.
Here's the link: http://www.orkney.jp/i18n-test.tgz
If this link test for you on windows, it works. :)

[mbasa@…]

Assefa, we'd appreciate it though if you can provide us the binaries also so
that we can do some tests with it over here. Thanks.

[assefa]

I have build libiconv (version 1.9.1) with libraray gettext (0.13.1) for
internatinal libarary.  Builds well out of the box.

I have then build gd (version 2.0.26) with iconv libraray (there is only one
file that seems to be involved in this gdkanji.c with a flag HAVE_ICONV. It
builds fine.

 I then build mapserver (with the USE_ICONV flag) against the gd library and
using the iconv libarary. It also buids well.

 I have then tested the demo files sent by Mario with the Encoding stuff in it
and I do not get *any text*. (no label on the map)

 Are there other libraries invloved ? Is there a problem with versions used (for
gd, libconv, gettext) ? What are the libs invoved on the Linux side ? Am i
missing libraries ?

[mbasa@…]

Assefa, please try commenting out all the "ENCODING" from the japanese.map and 
see if the labels are displayed, simillar to those of the screenshots. If the 
labels do appear, try re-building gd again, but this time without the kanji 
support. I think what is happening is gd is translating labels that have 
already been translated by libiconv. 

[assefa]

I did the rebuild of gd without the iconv and I was still having a problem. The
 iconv_open function call in mapgd.c (iconv_open("UTF-8", encoding); was
failing. I rebuild libiconv with debug infos to follow it, and the function was
returning the approprite values in debug mode and I was seeing the labels. To
make sure of that I rebuilt libiconv *without* debugging info and to my surprise
It was also working. Maybe I did something earlier but it was wierd.

 All this to say that I have now on windows a mapserver displaying ptoperly the
lables with the encoding (I compared the outputs from i18n.map, thai.map,
japanese.map, chinese.map to the screen grabs from Mario and the look alike).

 There was one other problem making mapserver crash at the end of the process
when  freeing the labels (functiob msFreeLabelCache). I did comment out this for
now locally but I need to understand why the crash happens before closing this bug.

 I will make a my windows version available for others to test.

 Last note (for myself :) : need to upgrade windows makefiles.

[dmorissette]

About the crash: I was looking at the code with Julien the other day and we saw
some anomalies that would definitely cause a crash. Julien was going to fix
them. I don't know if that's been committed yet.

[jlacroix]

My change was committed yesterday (mapgd.c => 1.67), if you use the last cvs
version of mapgd.c you should have it, so it will be related to something else
and we should open a new bug for this. This is weird since I ran valgrind on it
and everything was fine.

[assefa]

Using the most recent cvs, I do not get a crash anymore.

[mbasa@…]

Just a little note. The kanji (name given to Chinese and Japanese characters) 
support in gd has been added just recently to handle only Japanese 
characters.I don't know if they have plans to handel other encoding systems in 
the future. Anyway, since it only affects us here in Japan, we can document 
this locally. 

[dmorissette]

Assefa, can we close this now?

[assefa]

Yes It can be closed. I have updated the widows makefile to build with libiconv.
The latest widows executables on maptools.org contain the support of libiconv.

Marking it as Fixed.