On Wed, Jun 13, 2007 at 09:18:22PM -0400, hzluo wrote:
> I just tested and found that it's the Qt or M$'s stdc++ lib
> that made the mistake. LyX call Qt to convert filenames to
> UTF-32, and then call Qt again to convert it to local 8bit.
A working [untested] solution using Qt is
vector<docstring> getArguments(int argc, char * argv[])
{
vector<docstring> args;
QCoreApplication app(argc, argv);
foreach (const QString & arg, app.arguments())
args.push_back(from_qstr(arg));
return args;
}
Note that although this gets passes argc and argv, it does not
get used inside the QApplication constructor _on Windows_.
Instead some OS specific means is used there to retrieve the
original commandline and parse that.
argv cannot be used on 'real' 16 bit Windows, its contents is
already destroyed by the runtime when it gets passed into main().
> Finally, the converted results is transfered to i/ofstream
> to open the files. I know that M$'s libaray can _never_
> properly pass 8-bit strings, in any local... So, there may
> be two problems:
>
> (1) Qt uses incorrect local. I have printed some trace,
> and it seems Qt treat my local as latin1. I will double check this.
Please do. But I doubt this is a locale problem.
> (2) M$'s i/ofstream can't accept 8-bit string as filename. That's the
> worst thing, but M$ always do such disgusting things... Even though
> all other libraries can pass 8-bit strings in local encoding.
It can, but you don't have an 8 bit system, do you? And the xxxW
functions work on 16 bits. Our problem is that we do not want to
clutter our code with
#if WIN32 && isInTheMiddle(COUNTRY) && MOON_PHASE == full
Some Code
#else
other code
#endif
> My tex2lyx just successfully converted one .tex file with Chinese name.
> The filename is accepted from argv. But the file open procedure is
> changed. I'll check whether Qt properly handles my local. If so,
> it must be M$'s evil. If it's the case. we need to patch a lot of different
> places. All file open from fstream, and all file open from clib must
> be patched...
>
> Or, can we use another stdc++ and clib to replace it?
You mean QFile? This is the only working solution I am aware of
that does not lead to #ifdef's on the user side of the code...
Andre'
PS: And before more comments on some 'strange coincidence in time'
appear I want to remind everybody that my first push for more Qt
(especially Qt 4) for LyX support dates back to 2006 (if not 2005).
