[Insight-developers] Image writing with unicode filename impossible with MSVC

[Tom Vercauteren]

Hi Luis,

One solution we didn't mention would be to roll out our own unicode
aware string class. This has been done in VTK already:
http://www.vtk.org/doc/nightly/html/classvtkUnicodeString.html
https://www.kitware.com/InfovisWiki/index.php/Unicode_Strings

This would of course not be as feature complete as ICU but could
provide only the features we need (e.g. conversion to and from utf8
encoded char * and utf16 encoded wchar_t * on windows) and would thus
be much more lightweight.

Could such a class be factorized between the different Kitware
projects? The KWSys library seems to be a good candidate for that.
there is indeed already a wrapper for std::string:
http://www.itk.org/cgi-bin/viewcvs.cgi/Utilities/kwsys/kwsys_stl_string.hxx.in?root=Insight&sortby=file&view=markup

Is someone in particular responsible for maintaining kwsys? It looks
like most recent changes to kwsys were done by Brad King. Should we
put him in the loop?

Another lightweight candidate would be utf-cpp:
http://utfcpp.sourceforge.net/
It has several useful features and the license seems fine:
http://utfcpp.svn.sourceforge.net/viewvc/utfcpp/v2_0/source/utf8.h?revision=62&view=markup

Thoughts?

Tom

On Tue, Oct 13, 2009 at 18:16, Tom Vercauteren <tom.vercauteren at m4x.org> wrote:
> Hi Luis,
>
>> I'm curious of taking a look at other libraries and
>> seeing how they have managed this issue.
>>
>> A good candidate to learn from is Qt, since they
>> have such an international user base, and support
>> anything from KDE to cell phone applications.
>
> Indeed, QT handles unicode data quite nicely with its QString class.
>
>> [snip]
>> In short: I don't see too much trouble in
>> inserting this sort of modifications in ITK itself.
>> What will be tricky is to propagate this down
>> each one ImageIO class and their respective
>> libraries (PNG, JPEG, gdcm, Meta, Nifti).
>
> Agreed, this will require some tedious work and its not even sure that
> it will get accepted upstream. Below is some insight on the different
> third-party libraries.
>
> PNG and JPEG should not be an issue. The file is indeed opened by ITK:
> See the constructor of PNGFileWrapper and JPEGFileWrapper
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/IO/itkPNGImageIO.cxx?root=Insight&sortby=file&view=markup
> http://www.itk.org/cgi-bin/viewcvs.cgi/Code/IO/itkJPEGImageIO.cxx?root=Insight&sortby=file&view=markup
> This would require using _wfopen on windows (instead of fopen):
> http://msdn.microsoft.com/en-us/library/yeby3zcb(VS.80).aspx
>
> Looking at GDCM, the following seems somehow promising:
> http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=MS_Windows_questions#Is_Unicode_supported.3F
> "  Is Unicode supported? No (not yet)."
>
> A fix for Meta should be easy to port upstream I guess.
>
> NRRD can apparently be given a FILE * instead of a filename meaning
> ITK could handle the unicode question without modifying this third
> party library
> http://teem.sourceforge.net/nrrd/lib.html#io
> This would require using _wfopen on windows:
> http://msdn.microsoft.com/en-us/library/yeby3zcb(VS.80).aspx
>
> NIFTI doesn't provide much information on the unicode topic.
>
>
>> The option of using ICU is tempting.
>>
>> The license is fine:
>> http://source.icu-project.org/repos/icu/icu/trunk/license.html
>>
>> The source code size. however, is:   69 Mb.    :-/
>>
>> ITK itself (with all the third party libraries) is 133 Mb.
>>
>> I'm finding difficult to justify including such a large library
>> for dealing with a rather localized feature.
>
> Wow! I didn't realize that... However, apart from ICU, I don't know
> any good unicode library we could use. QString is not much better in
> this case since it would require all of QT core at least.
>
> The dependency on either QT or ICU could be optional but this would
> require even more ifdefs.
>
>
>> Let's start with the isolated experiment,
>> to test the waters...(that is, just a test that
>> doesn't modify yet any of the ITK classes).
>>
>> Would you like to take a first crack at it ?
>
> Sure, the test submitted by Benjamin (in the form of a patch) is
> already quite nice:
> http://public.kitware.com/Bug/file_download.php?file_id=2500&type=bug
>
> Should I simply go on and commit this patch or were you expecting
> something else?
>
> Tom
>