The sax-parser is choking on tags like 'section*' or 'Braille (default)'.
Also setting parameters like 'height=12pt' are not valid.
The added filter tries to 'correct' the input for the sax parser.
E.g. 'Braille (default)' ==> 'Braille__default_', 'section*' ==> 'section_'
and 'height =12pt' ==> 'height="12pt"'
All of these changes were due to
1.) Changed latex output (white space)
2.) changed reaction of dialog shortcut to return from
find-adv settings to search tab
3.) debug-mode of libstdc++
4.) LASSERT in InsetMathGrid.cpp
* invert failing lyx2lyx tests for ko/Welcome
* add dedicated test sample
* set language for English text part in ko/Welcome.
Also
* fix a lyx2lyx language test sample
* fix clause in unreliableTests
This happens with "inputenc: auto-legacy" if a language with default
encoding "utf8" (e.g. Turkmen or Mongolian) is used in a Quote
(or another environment).
Cmake's foreach command includes forms
foreach(<loop_var> IN LISTS <lists>)
foreach(<loop_var> IN ITEMS <items>)
foreach(<loop_var> RANGE ...)
We get the lines to be parsed by
file(STRINGS "${filepath}" lines)
If in the parsed lyx-file there is a line
containing only the single word 'IN', or 'RANGE', then
the command
foreach(_l ${lines})
can create a syntax error (at least with cmake1.16)
In fact, in file pl_Additional.lyx:12913 happens to have
such a beast.
Debian stable ships now TL18, we don't need to care for older TL versions.
Make CJK-ko documentation more robust (failed with non-TeX fonts and XeTeX,
if LatinModern is not installed system-wide).
The test sample for LyX bug 3059 triggers an error only with
"fontencoding auto-legacy" and can be safely ignored with non-TeX fonts.
Simplify user preamble.
Use common test document for Xe- and LuaTeX with polyglossia
and special one for languages only supported by XeTeX.
Update tagging patterns and comments.
LyX follows LaTeX in dropping support for this combination
(it only worked by tricking "inputenc.sty").
There is no known case where this combination is required or helpfull.
For power users with special needs, XeTeX + TeX fonts is still
available after setting the input encoding to "ascii" or "utf8-plain".
See also #10600.
Amends 7bb30286.
Tested cases are now handled fine.
(There are still many cases where the language support emulation
is too complex for lyx2lyx and manual fixes are required after
lyx2lyx conversion.)