LyX expectedly gives the following warning:
TextClass.cpp (1385): The layout does not provide a list command for
the float `sidebar'. LyX will not be able to produce a float list.
This issue was reported to the maintainer. This commit is consistent
with 00f7a95f.
It used to give an endless loop, so we "ignored" it (did not run the
test). Now it gives a lyx2lyx warning, which is reported at #11455,
so it is appropriate to invert the test.
The 001-4-latin_utf8x_pdf2 test passes and the
001-4-latin_utf8-cjk_pdf2 test fails, which means that there are
characters in the .lyx file that are only available with
utf8-extended encoding, so the utf8 test is never expected to pass
in the future.
Thanks to Kornel.
utf8-plain (Unicode (utf8 XeTeX)) is a power-user setting
for the input encoding with two use cases:
a) setup of system fonts or
b) setup of input encoding supportuser preamble
in the document class or user preamble.
The test file is an example for use case b.
The Korean splash.lyx is expected to fail with pdflatex. The lyx22x
and lyx23x tests were not failing before because they were exporting
to XeTeX with system fonts, which succeeds. After c9e62dec (which
corrects the export format to the default), the lyx22x and lyx23x
tests should be inverted.
Use the LaTeX internal character representation (LICR) macros
provided by lgrenc.def (since version 0.8 from 2013-05-13)
in lib/unicodesymbols. This fixes the PDF bookmarks (except for the
legacy input encoding iso-8859-7) and solves the problem of a missing
"v" character in Libertine LGR fonts (see lyx-users from 2018-01-29).
The ctest unicodesymbols/008-greek-and-coptic_iso8859-7_pdf2" now fails
(due to #9681). This is not a regression, as it is already
"unreliable" (wrong output, Latin character instead of Greek).
Drop compatibility definition of \~ as perispomeni accent
(that was required with lgrenc.def < 0.8).
The export ja/lilypond_pdf fails because ps2pdf gives an error. It
is thus still inverted, under the category 'externalissues'. As
Jürgen discovered, ps2pdf succeeds if the -dNOSAFER flag is used.
Note that Kornel is seeing strange behavior with the sweave test,
and thus the label of that test might be changed soon (e.g. to
"unreliable"). For discussion, see:
https://www.mail-archive.com/search?l=mid&q=20171001032524.fr5xfngylththwv2%40steph
This test started failing after 8bf3d7bb. I did not look deeply into
why, because the corresponding de and es tests were already
inverted, and because in general we do not expect texF tests to work
well.
iconv fails, if a nomenclature inset contains an uncodable character
This led to failure of the indonesian UserGuide in the attic.
Fix it there and add a minimal, specific test sample instead.
