Scott Kostyshak wrote: > On Tue, Jun 17, 2014 at 8:55 AM, Seunghee <[email protected]> wrote: >> >> Hi, Scott, >> thank you for your reply. >> I have installed lyx2.2dev and tried to input Korean in the both of >> modes. >> >> In the 'Program Listing' mode the problem is fixed, but not in the 'tex >> mode'. >> >> I have found a difference between the both of modes. >> Wenn I input alphabets in the 'program Listing' mode, the following >> message appears: >> "Font: Typewriter, text, Language: LaTeX" >> >> But in the 'tex mode'the following message appears: >> "Font: Typewriter, LaTex text, Language: LaTeX" > > Georg, do you know what's going on here?
Yes. The behaviour is by design. The explanation of the reason is a bit technical: Since version 1.5.0 LyX uses unicode internally, and .lyx files are encoded in utf-8. The big advantage of that compared to previous versions is that LyX can process and display text in almost all languages on earth. However, when LyX exports the document in LaTeX format for typesetting production, the situation is much more complicated. There are the modern LaTeX compilers like XeLaTeX and LuaLaTeX, which (like LyX) use unicode natively and take utf8-encoded input files, and there is the traditional LaTeX compiler which uses an 8-bit encoding internally and takes input files in different encodings, or even using multiple encodings in one file. The difference between 'Program Listing' and 'tex mode' is the following: 'Program Listing' is typeset using the listings LaTeX package, and that package supports a variety of different encodings. Therefore, when a 'Program Listing' is output, LyX tries to find a suitable encoding which is supported by the listings package, and then converts the contents of the 'Program Listing' into that encoding. This works usually. However, 'tex mode' means that the contents of the ERT inset is output 1:1, no transformation is allowed by definition (otherwise it would not be raw TeX anymore). This means that the contents must either be encodable in the currently active output encoding, or output would fail. Unfortunately, due to an internal limitation, we don't know the currently active output encoding where we need to know it (for LyX developers: latex_language- >encoding() returns a static encoding, this needs to be dynamic and depend on the current environment). I want to change that in the long term, but this is the current situation. Since you can get an uncodable document so easily with ERT insets, bug 9012 was filed, and we fixed it by disallowing non-ASCII characters in ERT insets. Before the long term solution is implemented, we have two options: Reverting the fix for bug 9012, and live with the easy way to create uncodable documents, or do nothing and live with the fact that non-ASCII stuff does not work in ERT also in the cases when it would be encodable. As a workaround for your problem, you can split your ERT inset in several parts, and put the korean text in standard mode. Georg
