First run of Kornels patch for tests with all input encodings in lib/encodings.
Remove redundant sample files - keep only one sample and change the input encoding in the test script.
Put remaining failing test in "unreliableTests" for later sorting...
* custom non-tex fonts with all required characters
* use 2.2 fileformat (easier backporting)
* test all export formats
Also, fix pattern for "mixing_inTitle_layouts" in unreliableTests.
Specify non-TeX fonts that work in the source for documents that
fail with "missing characters" if compiling with "non-TeX fonts"=true.
(This does not interfere with the default output in any way.)
Add an exception to the conversion of "missing character" warnings into errors.
The PGF package deliberately uses the dummy font "nullfont" to suppress output.
Therefore, warnings about missing characters in "nullfont" are really only warnings.
Also updated the comment: "Missing character" warnigns are especially widespread
in XeTeX/LuaTeX but can also happen with "classical" 8-bit TeX.
Feel free to port this to branch.
Move them to a subdir, ignore this subdir for other tests.
Dedicated test samples for LaTeX-specific problems don't give additional value if tested for loading, conversion, or other exports.
This led to errors when compiling with polyglossia (and non-TeX fonts).
A minimal (currently non-compiling) test sample is kept in autotests/export/
and inverted in suspiciousTests.
europeCV and modernCV examples can now be exported to PDF using
LuaTeX. For the specific output that was fixed, look at the diff and
see the description in suspiciousTests that was removed by this
commit. The output was checked manually and appears fine. These
tests are thus "uninverted".
Exporting those examples to DVI with LuaTeX does not exit with
error, but the output drops characters with accents. Thus, these
tests are now marked with the "wrong_output" label. I reported this
issue on the LuaTeX mailing list at [1], but since DVI export is not
given high priority, I don't expect much action.
Note that these changes reflect an updated TeX Live 2016
installation.
[1]
https://www.mail-archive.com/search?l=mid&q=20160831134006.4fewxothddqfeyw4%40steph
As of 0b1cf133 we now warn in the GUI of this issue, but there is a
discussion about whether we should change our LaTeX output and allow
for the workflow of mixing inTitle layouts. For more information,
see #10347.
The keytests were previously enabled by default if the necessary
dependencies were found. They require a GUI and mouse so can
sometimes be annoying. Further, they are not currently reliable.
They are thus now disabled by default.
XeTeX with TeX fonts is only safe with ASCII input encoding (see #9740)
and we therefore force "ascii" when exporting with XeTeX and 8-bit TeX-fonts.
However, "utf8-plain" is a "power-user" option, which allows to switch off LyX's
encoding of the LaTeX file:
keep this also for "XeTeX with TeX fonts".
The user is responsible to ensure all characters can be processed and are
correctly shown in the output. The provided test sample shows the problems
with this encoding without special measures (like loading fontspec in the
user-preamble or a document class).
In collaboration with Günter Milde:
1.) Allow char ':' be part of a ctest-label
2.) Eliminate redundant label naming and directory names
(The testnames should not repeat the directory name)
When updating to the latest TeX Live revision, these exports now
succeed.
Inspecting the differences between the "good" PDF and the "bad" PDF
(where the test failed) there are three differences, which can be
found on the printed page numbers 81 and 82 (PDF page numbers 91 and
92). The accented i in "lím" was printed incorrectly (and the
missing glyph was correctly detected). After the update the
character is printed correctly and there is no longer an error.
The package that caused the change is likely babel or babel-spanish.
You can see the log from the TeX Live update that caused the fix by
seeing the attachment to the message here:
https://www.mail-archive.com/search?l=mid&q=20160313015902.lny3g5aujh4c4aps%40scott-Za1510
It could happen that the variable was set in creating a previous test-case.
Some combinations in the controlling files (suspiciousTests, unrelibleTests, ...)
did not set this variable.
