[vtkusers] VTK 6.1 no longer supports ASCII characters > 128? (5.10.1 was ok)

Sean McBride sean at rogue-research.com
Wed Jan 21 17:16:55 EST 2015

On Wed, 21 Jan 2015 15:26:14 -0500, Serge Lalonde said:

>The same must be done to handle file names coming from a user in case it
>also contains Unicode characters:
>   pWriter->SetFileName(vtkUnicodeStr
>ing::from_utf16((const vtkTypeUInt16 
>*) marshal_as<std::wstring>(file_path).c_str()).utf8_str());
>Unfortunately, the writers (and probably the readers) still use fopen()
>in the internal code which can't handle UTF-8 encoded filenames.

Using fopen() isn't a problem.

The question is: what character encoding does fopen() expect?  Remember, it's char* parameter tells us _nothing_ about the expected encoding, it could expect ASCII, Latin1, UTF-8, UTF-16, or anything else.  Only the documentation can tell us.  And it could expect different things on different platforms. :(

On probably all modern UNIX variants, it expects UTF-8.  On Windows, it might expect something else, you'd have to check Microsoft's docs.

From VTK's perspective, this means that the path argument expected by readers and writers should be in whatever encoding the host OS expects for APIs like fopen(). 

I can confirm for example that the vtkSTLReader on OS X can open filenames with emoji and other crazy stuff just fine.


Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

More information about the vtkusers mailing list