Guenter Milde wrote: > On 2013-03-27, Georg Baum wrote: >> Guenter Milde wrote: >>> This is why I propose: >>> * document the issue (for all included files!) >>> * use the "locale encoding" for LaTeX export. > >> What do you mean by "locale encoding"? If it means that the encoding is >> derived from the OS, i.e. the LANG and LC_* environment variables on >> linux, I strongly disagree. The output of a document should never depend >> on the preferred language of the user interface. It should always be >> completely determined by the .lyx file alone. > > I got your point. > My idea was, of course, not to replace the manual choice of "LaTeX > encoding", but a different default.
I see. Nevertheless I still believe that this would cause other problems, see below. > Without file inclusions, the "LaTeX encoding" of the exported file does > not matter for the Postscript/PDF-generation: > > * The encoding of the LyX-document itself is always utf8 (since several > versions of LyX). > * (re) import into LyX converts the from the "LaTeX encoding" into utf8. > * With 8-bit LaTeX, every non-ASCII character is converted to LICRs > (either by LyX (if the encoding is set to ASCII, or by the inputenc > package). > * With (Xe/LuaLaTeX), the LaTeX encoding is always utf8. In theory you are right. In practice this is not always the case for 8-bit LaTeX. Either you choose utf8 encoding. In that case you need to load any of the existing utf8 support packages like utf8 or utf8x, but none of them is complete. Also, listings do not work with utf8. Or you choose any other encoding, but in that case you rely on lib/unicodesymbols, which is incomplete as well, and may even load packages that are incompatible to each other. > For included files it is IMO quite sensible to assume the locale encoding > as a first guess. If the "LaTeX encoding" and the locale encoding are the > same, chances are best that no re-encoding is required. Why is it sensible to choose the locale encoding? This assumes that the document language matches the locale, but this is an invalid assumption IMHO, as I tried to explain. I know that many text editors assume that as default, but that does not make it better. >> Otherwise you get trouble if users edit a >> german document on an english OS etc. > > The current default is even worse. If a user wants to edit the > LaTeX-export of a German document on a system with "locale encoding" > UTF-8, say, she must either: > > a) manually set the "LaTeX encoding" under Document>Settings>Language>... > b) use an external conversion tool from latin9 to utf-8 > c) use a text editor that understands several encodings and also remembers > to > translate the "inputenc" argument when re-encoding. > > b) and c) have a very important glitch: with the current default, they > will (most probably)¹ break the document if it uses second language that > has a different default encoding (Russian or Greek, say). > > ¹ There are not many editors or tools that can savely handle text > documents > with in-document encoding switches. Indeed. Emacs can do it, AFAIC kile cannot do it although it is a LaTeX editor. > This is why, the current default (language-dependent multi-encoding) > is an outdated and very bad choice. It was justified to a certain degree > when LyX still used 8-bit encodings for the *.lyx file itself but this is > now several years ago. I do not agree. The main purpose of the exported LaTeX is not to be edited with a text editor, but to be typeset. For the latter purpose the default is IMHO still the best one, at least as long as utf8 support is as limited as nowadays in 8-bit LaTeX. I would like to switch to uniform utf8 as default rather sooner than later, but to my knowledge this is not possible yet (we do not only need to think of languages supported by babel, but also more complicated cases, e.g. thai or CJK). If somebody wants to export for further manual editing the text, he either needs to use an editor that is smart enough to handle in-document encoding swicthes, or manually set the encoding in LyX. If the complete document is in one encoding then I don't see any problem. We can expect from any modern editor that it works with different encodings. What we should probably do is to enhance the documentation, and explain the pros and cons of the different encoding options in more detail. > Considering, that UTF-8 is nowadays the default on most systems, I'd > recommend to change the default. However, only after bug > http://www.lyx.org/trac/ticket/8600 > is fixed. There are more, http://www.lyx.org/trac/ticket/8408 and http://www.lyx.org/trac/ticket/6789. Georg
