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

[Luis Ibanez]

Hi Tom,

Your suggestion of moving vtkUnicodeString to kwsys
makes a lot of sense.

We are checking with the maintainers of kwsys, to see
if there are any drawbacks...

--

The second option:  adopting the  utf-cpp  library, also
looks good. the license is essentially the MIT license:
http://www.opensource.org/licenses/mit-license.php

and the size of the library is just 132 Kb.


Let's see first what we hear from kwsys gurus.



   Thanks


       Luis



-----------------------------------------------
On Wed, Oct 14, 2009 at 3:41 AM, Tom Vercauteren
<tom.vercauteren at m4x.org> wrote:
> 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
>>
>