Bug #851
Please support std::wstring in exiv2 path access
100%
Description
Hi there,
I found a bug in exiv2, which does not allow to open Images when the filename of the image is using std::wstrings.
Following the MSVS2010 error i get when using wstrings as parameter in FileIO. ( I do get the same error in Exiv2::ImageFactory::open(...).)
error LNK2019: unresolved external symbol "public: __thiscall Exiv2::FileIo::FileIo(class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > const &)"
What i do now is using QString conversions to produce a std::string from the std::wstring filename ("Exiv2::ImageFactory::open(QString::fromStdWString(m_Image->GetFileName()).toStdString())", which of course works for english filenames. As soon as I'm trying (and finally this is my goal) to load filenames with chinese, japanese or german umlauts i do not get any reasonable outcome.
I would be really happy if you find a way to solve this, I could not find one until now.
Thanks a lot in advance
donny
Associated revisions
History
Updated by Robin Mills about 9 years ago
- Category set to build
- Status changed from New to Resolved
- Assignee set to Robin Mills
- Target version set to 0.24
- % Done changed from 0 to 100
Thanks to Thomas for answering this one.
I'm going to mark this as resolved/100% complete. However if Donny has further questions, the issue remains open and Donny (or anybody else for that matter) can add an update. It'll be closed during bug-review prior to the 0.24 release.
Updated by Andreas Huggel about 9 years ago
Thomas, is this working for you with a recent revision of the code?
Both msvc/include/exv_msvc.h and msvc64/include/exv_msvc.h contain a line #define EXV_UNICODE_PATH so it seems to me the Unicode paths should work out of the box, unless we broke something recently (or the precompiler define was disabled manually).
-ahu.
Updated by Andreas Huggel about 9 years ago
Robin,
Just noticed that config/config.h.cmake does not mention the EXV_UNICODE_PATH define at all. So if the library is compiled using cmake, Unicode paths aren't enabled.
Could that be added to config/config.h.cmake in such a way that it automatically gets defined on Windows platforms (which support Unicode paths)?
-ahu.
Updated by Robin Mills about 9 years ago
- Status changed from Resolved to Assigned
- % Done changed from 100 to 50
Good point. I'll investigate. I've reset this issue to 50% done/assigned and I'll take care of the CMake implications. If Donny or Thomas wish to say anything about this, I'll be happy to help.
Updated by Markus Diem over 8 years ago
we had the same issue. the problem is that we had to set C/C++ > Language > Treat WChar_t As Built in Type to No (/Zc:wchar_t-) in order to get functions such as QString::toStdWString(). in your default solution it is set to Yes (/Zc:wchar_t). So if it is set to No (/Zc:wchar_t-) in the default exiv2.sln this issue is solved. It would be nice if you could mention this somewhere in the API for other Qt users.
Updated by Robin Mills over 8 years ago
Donny
Thanks for bringing this to my attention. I had forgotten about this. I'll investigate it after work this evening and update this bug report.
Robin
Updated by Robin Mills over 6 years ago
- Target version changed from 0.25 to 0.26
Deferred to v0.26. Insufficient time to deal with this for v0.25.
Updated by Robin Mills about 6 years ago
There's been a forum query about this in relation to Qt. I'm going to work on this. http://dev.exiv2.org/boards/3/topics/2311
Updated by Robin Mills about 6 years ago
- Status changed from Assigned to Resolved
- % Done changed from 50 to 100
- Estimated time set to 10.00 h
I've done some work on this. I'm going to mark this as Resolved/100% and intend no further work at this time. I think the library builds and operates correctly. If it didn't somebody using Qt would have reported issues with this. However, our sample applications have not been modified to use wmain on windows and thereby using unicode paths.
The way in which the EXV_UNICODE_PATH has been used surprised me. Calls such as path() get built as wpath() and so on. When I've dealt with unicode in the past, we've used UNICODE as the "core". Ascii interfaces convert their arguments to UNICODE and call the "core" functions. It would take considerable effort to rework a basicio to adopt this strategy and update all the sample applications. There is unknown risk involved. So, I ask myself the question "why bother when nobody has reported bugs in the UNICODE_PATH implementation?".
So, I've decided to do no further work on this matter.
#851 Changes to CMake option -DEXIV2_ENABLE_WIN_UNICODE={OFF|ON}