In export.cmake, if the detected output format is pdf3, we try to
export to "platex", which usually makes sense, but for this file we
would need to export to "latex". This file is very particular, and
also old, so I do not know if it is worth the time to handle this
case.
This commit inverts the following tests:
export/examples/Articles/Chess/Game_1_lyx16 (Failed)
export/examples/Articles/Chess/Game_1_lyx20 (Failed)
export/examples/Articles/Chess/Game_1_lyx21 (Failed)
export/examples/Articles/Chess/Game_1_lyx22 (Failed)
export/examples/Articles/Chess/Game_1_lyx23 (Failed)
These fail when exporting to TeX, but since they have to do with old
formats, it's not clear it's worth the time to investigate.
These started failing once we check the exit code of LyX's TeX
export (at c7be9780).
Now that we detect and export to the correct TeX format (instead of
assuming pdflatex), we can make the check more strict by giving an
error if LyX exits with error from the export.
This fixes the following tests:
export/examples/ja/Modules/Rnw_%28knitr%29_lyx22
export/examples/ja/Modules/Rnw_%28knitr%29_lyx23
export/examples/ja/Modules/Sweave_lyx22
export/examples/ja/Modules/Sweave_lyx23
The only difference from regular letter is the alignment of
"Send To Address" layout, but it no longer reflect the output
corrctly, probably because LyX revert the alignment of layouts
in RTL context now.
The warning says:
CMake Deprecation Warning at .../CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Spotted by Scott Kostyshak
This makes things much simpler.
But at least with the latest macos tools (Sonoma and XCode15) a bundle
refuses to run if it 's not signed properly.
Both issues are solved with the patch included and have now been tested
with Qt5.15 and Qt6.7.
For completeness: I've checked the font-emph shortcut issue and, as
reported in the ticket mentioned, ^CmdE works with Qt5.15 but not with
Qt6.7. However the sequence ^C E does work. I don't know whether this is
intended as a workaround for this issue or was already implemented.
It seems that utf8x is not supported, or needed, on updated TL. From
David Carlisle:
utf8x by default does nothing now, but as a compromise
compatibility for some specific existing documents if you
explicitly load ucs then it and utf8x work as before, but that
over writes all of latex's default unicode handling and things
will go wrong. There really isn't much that can be said other than
don't load the package. The alternative would be to make ucs do
nothing as well, but that would stop some documents working that
currently work.
