Although this is a very nice idea anyways, but you are aware, that this massively "complicates" the compilation on Windows, right?
Not really. GTK+ team uses
win_iconv on Windows which is purely written in Win32 API and is very easy to compile on Windows. Visit it's homepage (You need to translate it) :
http://yukihiro.nakadaira.googlepages.com/
Or just download the compiled package from the following page.
http://www.gtk.org/download-windows.html
I'm not sure on how many libs iconv itself depends but I would guess it's not a "stand-alone".
It has no external chain of dependency. So rest be assured that it'll not increase the overhead.
So the question is either we find another solution or probably (as this seems to be a Linux only thing) we make this implementation on Linux only... Any thoughts?
IMO, we can make the changes for Linux only where
libiconv.so is available.
But my real concern is not the compilation of
iconv on Windows or so. My major concern is to see that the iconv and wxWidgets work together without creating nuisance. That's why I thought of wrapping iconv as a separate plugin so that it doesn't affect the core code.
I've already noticed problems with some encodings with the new patch. wx fails to accept the passed wchar_t pointer and the conversion looses several paragraphs of characters. I guess it's about more number of NULL chars at the end confuses wx.
correct me if I'm wrong, biplab, but all you need to do to make this operational is to add a function that maps the wxFontEncoding typedef to the strings that iconv can handle?
Yes it is. IIRC, iconv supports more encodings than wx handles. That's one reason I wanted to implement it as a separate plugin. Also read the problem I wrote in previous para.