kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

Hi folks,

 I spent a few hours looking into the (final?) MinGW/UTF8
filename issue within KiCad and here is what I found:

Issue: arguments to external tools which contain non-ASCII
characters are not handled correctly.

What had been done:
+ on STEP export, within kicad, print the command line as
UTF8 to a diagnostic file. Result: everything is as expected;
file paths (output filename and input filename) contain
non-ASCII characters

+ within kicad2step: print the arguments as UTF8 to a
diagnostic file. Result: non-ASCII characters are not
preserved by the wxCmdLineParser. Next I tried to
access the data within wxAppConsole::argv - this data
is also corrupted. I haven't found time yet to dig deeper
into the wx source to see where things may have gone
wrong.

+ Reading the source for wxExecute it appears that
the command line is converted to UTF16 and
CreateProcessW is called. To verify this I built a
dummy kicad2step.exe using VisualStudio. This
dummy simply takes the command line arguments,
converts from UTF16 to UTF8, and writes to a
diagnostic file. The diagnostic file contains the
uncorrupted data, thus demonstrating that
wxExecute (kicad's side) is doing the right thing and
that it is the wxAppConsole (in this case kicad2step)
which is corrupting the data.

Does anyone have some idea what is going on?
If a Windows user launched, say, pcbnew from a
MinGW environment and the project name had a
non-ASCII character in it, does pcbnew do the right
thing or can that PCB file only be loaded from
within the running GUI? I'd like to find out if this
MinGW arg mangling affects more than I originally
thought - or if I'm doing something really stupid and
unwittingly causing the mangling.

- Cirilo