Mail Archives: cygwin/2011/12/08/07:38:20
Corinna Vinschen writes:
>
> Which raises the question why the Cygwin version of lyx uses
> cygwin_conv_path at all. Does it call Windows functions with the paths?
> If so, why? If not, why are the paths converted to Windows?
Because the user *could* enter Windows paths (e.g., for including images)
or a document created with a native Windows version could be opened with
the Cygwin version. The Cygwin version of lyx works internally with
posix paths, which are to be converted from the native Windows form.
Then, there is a case where the posix->windows conversion is needed.
Indeed, lyx allows to use either a Cygwin or native-Windows TeX engine.
There is a configuration check for this case. If a native-Windows TeX
engine is detected, all paths going to latex files should be converted
to Windows, otherwise the TeX engine would not understand them.
This is symmetric, i.e., if you compile a native Windows version of lyx
and use a Cygwin TeX engine, all paths going to latex files gets converted
to posix form. But this case is not of interest here, of course.
However, I experimented a bit with the last snapshot, and even using Greek
or Japanese characters in file names, lyx seems to be working fine. In part,
this may be due to the fact that, for compiling a latex file, all needed
ancillary files are copied to a temporary directory with their names
mangled such that only pure ascii characters are used. Anyway, when
converting from/to Windows, lyx assumes that cygwin_conv_path does not
play tricks with the encoding. It was so until now. If this changes, I
think it is bound to fail in some way.
--
Enrico
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -