On 2019-03-29, Jürgen Spitzmüller wrote: > Am Donnerstag, den 28.03.2019, 17:51 +0000 schrieb Guenter Milde: >> Changing the default input encodings in "lib/languages" creates a >> backwards-incompatibility that cannot be solved for some documents.
>> A lyx2lyx conversion (as outlined in >> https://www.lyx.org/trac/ticket/11115#comment:16) will break >> documents >> with text parts in Japanese, Chinese, Korean, Arab, or Farsi and >> "\inputencoding auto", because >> a) the setting "\inputencoding auto" has two components: >> * use the encoding as specified in "lib/languages" as main >> encoding >> * switch the input encoding for text parts in different languages, > Please provide an example file for this. Take the file autotests/export/latex/CJK/en-de-el-ru-zh_CN_language-default.lyx It compiles fine with the inputenc settings: "auto", "utf8", and "utf8-cjk" but not with any of the fixed-width 8-bit encodings: Changing to the present English default encoding "iso8859-15" results in the error Could not find LaTeX command for character '就' (code point 0x5c31) and no output. An example for Arabic as secondary language is autotests/export/latex/en-ar_language-default.lyx Again, it fails with input encoding set to "iso8859-15". > I am sure this can be fixed in a clean way. In any case, giving up the > Encoding option in languages is not an option. >> b) these languages are only supported with a "native" fixed-8-bit >> encoding or utf8. > Don't understand. There are no definitions for Arabic characters or CJK charactes in lib/unicodesymbols. Therefore, characters from the Arabic, Chinese, Korean, and Japanese script are only supported, if they are handled by LaTeX's inputenc package: * The CJK package adds handling of CJK characters (for utf8 and some "native" legacy encodings) * The Arabi package adds handling of Arab characters (for utf8 and cp1256) >> What are the benefits of changing default encodings in >> lib/languages over changing "\inputencoding" in templates and >> examples? > Changing the templates only helps people who use templates. Many users > don't (I don't use templates, for instance, except for my own ones). > And many also don't have a defaults.lyx template you could change. Ah, I did not expect that. > So with your solution a significant group of users will stick with 8bit > encodings forever. This is easily solved by changing the default default: diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp index de46966f2e..028889cd66 100644 --- a/src/BufferParams.cpp +++ b/src/BufferParams.cpp @@ -425,7 +425,7 @@ BufferParams::BufferParams() fonts_sans_scale[1] = 100; fonts_typewriter_scale[0] = 100; fonts_typewriter_scale[1] = 100; - inputenc = "auto"; + inputenc = "utf8"; lang_package = "default"; graphics_driver = "default"; default_output_format = "default"; This trims down the group of users that will stick with fixed-with 8-bit encodings to users with custom templates (including custom defaults.lyx). However, these users will need to manually update their templates anyway. > I have this on my agenda, and I will definitely go on to change > languages for 2.4.0, so be aware that all work you do on templates > might be wasted time. Please don't force this unless a) it does not break any tests, or b) a majority of developers agree that it it OK to break these tests. Günter
