| delorie.com/archives/browse.cgi | search |
On 12/8/2011 9:48 AM, Enrico Forestieri wrote:
> Andy Koppe writes:
>>
>> On 8 December 2011 00:33, Enrico Forestieri wrote:
>>> Corinna Vinschen writes:
>>>>
>>>> Just so it's clear why I did that, maybe you want to have a look into
>>>> the brief discussion on the cygwin-developers list:
>>>> http://cygwin.com/ml/cygwin-developers/2011-11/msg00000.html
>>>
>>> All good reasons, but you are going to break backward compatibility.
>>> At least, lyx is going to be affected. It currently works with unicode
>>> without a glitch
>>
>> That's impossible if it's using Ansi APIs.
>
> That is not the issue. No Windows API is directly used, but there is the
> need to convert from posix to Windows paths when the TeX engine is native
> Windows. The assumption that cygwin_conv_path does not change the encoding
> is made (this is so until 1.7.9) and if this is going to change it will cause
> havoc. Indeed, the path should be written to the latex file according to the
> encoding used (e.g., \usepackage[cp852]{inputenc}), and lyx takes care of the
> needed conversion. But, if the encoding is changed by cygwin_conv_path ...
I don't use lyx (though I use tex extensively), so maybe there's
something I don't understand. But is it really necessary for Cygwin's
lyx to support a native Windows tex? Wouldn't it be more reasonable for
users of a native Windows tex to use a native Windows lyx?
Ken
--
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
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |