PM> As a consequence, code prior bug #695120 fix may have worked for non 8-bit characters in filename,
AFAICT, it didn't work before (tested from 0.45.1 to now).
PM> providing the procedures called by Inkscape::Extension::open() (directly or indirectly) that really deal with the filename properly take care of the effective filename character type
Inkscape fails when calling Inkscape::IO::file_test (in src/io/sys.cpp:181). g_file_test always return false when the filename is an URI (tested with http:// and file:// schemes). Note that the filename is first tested and (if necessary) converted to utf8.
Thus I second ~suv. It looks like g_file_test() (and probably other g_file_* functions) doesn't support URIs on Windows. Unfortunately, I haven't found any relevant documentation on that potential issue.
~suv> the proposed patch does not have a negative _side effect_ for the Windows port
Yes. I suggest we commit the patch and open a new report to deal with the Windows issue.
PM> As a consequence, code prior bug #695120 fix may have worked for non 8-bit characters in filename,
AFAICT, it didn't work before (tested from 0.45.1 to now).
PM> providing the procedures called by Inkscape: :Extension: :open() (directly or indirectly) that really deal with the filename properly take care of the effective filename character type
Inkscape fails when calling Inkscape: :IO::file_ test (in src/io/ sys.cpp: 181). g_file_test always return false when the filename is an URI (tested with http:// and file:// schemes). Note that the filename is first tested and (if necessary) converted to utf8.
Thus I second ~suv. It looks like g_file_test() (and probably other g_file_* functions) doesn't support URIs on Windows. Unfortunately, I haven't found any relevant documentation on that potential issue.
~suv> the proposed patch does not have a negative _side effect_ for the Windows port
Yes. I suggest we commit the patch and open a new report to deal with the Windows issue.