ENH: use utf-8 via manifest on Windows#1401
Conversation
|
Very interesting, thanks Bernhard! I see you did quite some research to get it right 👍 👍 👍 I think it would be good to have a test for this improvements. Similar to the existing test on spaces in output path names: elastix/Testing/CMakeLists.txt Lines 445 to 453 in 796175c Do you still have time to add such a test? Otherwise, I'll see if I can add it myself. |
Done (see added commit). Since I'm not really familiar with the intial transform file format, I just added the first (AI-generated) content that made elastix run successfully (it might not really contain a useful transform). |
|
Thanks @codeling, looks cool! By the way, GitHub warns me that your commits are "Unverified", saying:
Do you have a clue? Otherwise I think I'll just ignore the warning 😃 |
e44a181 to
64cfb10
Compare
Ah yes, I typically sign my commits but hadn't set it up on that machine yet. I have resubmitted my changes now as single squashed signed commit! |
64cfb10 to
d73dafc
Compare
|
In a ctest run, 3 tests are failing ( |
N-Dekker
left a comment
There was a problem hiding this comment.
Thank you very much, Bernhard! Really cool!
Elastix was not able to correctly handle special characters in some folder/file name parameter input on Windows; Elastix would interpret those names incorrectly, resulting in errors.
Test cases:
-out C:\tmp\elöx\result-transform:(The folder
C:\tmp\elöx\result-transformdid exist before the call)-t0 C:\tmp\elx\input\initialTransförmParameter.txt:(the file
C:\tmp\elx\input\initialTransförmParameter.txtdid exist before the call)-m C:\tmp\elx\input\möving.mha/-f C:\tmp\elx\input\fäxed.mha)-t0parameter is already read as UTF-8, and a .h5 file referenced from within that file (TransformFileName) is already correctly loaded when containing special charactersThis PR fixes the 2 failing test cases specified above. It adds an application manifest to switch the executable's locale to utf-8 (available since Windows 10 1903, so for every still supported Windows version); this is same as e.g. applied in Slicer . Also the console output is switched to utf-8.
Note: A similar workaround (but setting locale to utf-8 systemwide instead of for the application alone) was already proposed in this issue way back in 2021 for fixing special character issues; the way this PR handles it does not require any action by the user and should just enable special characters working fine on any system >= 1903.