Kornel Benko wrote: > Thanks for clarification. Nonetheless, we have a mess here. > 1.) Reading .lyx without need to convert (e.g. in current lyx-format) > works regardless of environment (This is done by lyx directly, without > interpreting the file-name)
Probably because you loaded it from recent files, where the name is stored in utf8. Try to load it via command line, that will probably cause similar problems. > 2.) Reading .lyx with lyx2lyx does not work. > So my question: Why not pass the filename to lyx2lyx (or any other > program) without _any_ interpretation? Because then we would need two pipelines for file names in LyX: One using unicode, one using an unknown encoding. We would not be able to convert between these two, we would not be able to display filenames in the unknown encoding, and it would be too easy to interpret them as utf8 by accident. Also, some file names are generated internally from others, we cannot do that without knowing the encoding. IMO it is good that LyX uses the unicode-aware docstring internally for everything which can be non-ASCII. Conversions should be done at the interfaces where needed. The question in your case is now how exactly we can make QFile::encodeName() use the wanted encoding: 1) Which environment variables are used by QFile::encodeName() to determine the encoding? 2) Does our own locale manipulation (see e.g. init() in os_unix.cpp) interfere with that? If we know the answers to these two questions we know whether the current behaviour is OK, or whether we need to file a bug report to qt, or whether our usage of locales is wrong wrt QFile::encodeName() and we need to do something on our side. Georg
