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).
If, after the 10th iteration, the exported lyx16x file still
differs from the one in the previous iteration, the test
is marked as failing, even if still loadable.
The "bxjsarticle" class only supports export with XeLaTeX and system
fonts.
This commit uses the new exclusion functionality introduced at
10cd5dd2.
The following tests are now ignored:
export/examples/ja/knitr_dvi
export/examples/ja/knitr_pdf
export/examples/ja/knitr_pdf3
export/examples/ja/sweave_dvi
export/examples/ja/sweave_pdf
export/examples/ja/sweave_pdf3
The following tests are no longer ignored:
export/examples/ja/knitr_pdf4_systemF
export/examples/ja/sweave_pdf4_systemF
This allows us to exclude matches of certain patterns in
invertedTests, ignoredTests, unreliableTests, and suspendedTests.
To use this new functionality, prefix "!" to the pattern.
This functionality serves as a workaround in some cases to not being
able to use advanced regular expression techniques, such as
"negative lookahead", with CMake's regular expression engine.
Output of "ctest -N" is unchanged by this commit.
This functionality will be used soon (see next commits).
Patch from Kornel Benko.
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
Handle name may be arbitrary string mathing '[A-Za-z0-9]*'.
This is then used by appending to the commands for the control file.
For instance select 'Alpha' as handle for the control file 'abc'
'COAlpha: abc' ==> open 'abc' for write
'CCAlpha:' ==> close 'abc'
Could not find a suitable tex font for the following tests:
export/doc/uk/Intro_pdf4_texF
export/examples/uk/splash_pdf4_texF
export/examples/minted-filelisting_pdf4_texF
1.) Handle also 'LatexCommand inputminted' in lyxStatus.pm
2.) Add '-shell-escape' to the appropriate converters.
This applies only to the ctest-environment iff calling
the script 'prefTest.pl' in the build directory.
keytest.py: This gives the os some time to update the status.
All keys with modifier and all possible shortcuts are affected.
Shortcut use corrected in findadv-11-in.txt and findadv-17-in.txt
Now, before starting a test with 'TestBegin' in any *-in.txt file
we can create ne shortcuts used by this test.
Defining a shortcut:
UseShortcut "<shortcut>" "<function>"
Actually adding the new shortcuts to be used by the next lyx-session:
PrepareShortcuts
Use example is found in findadv-combined-in.txt
The UseShortcut-entries will be traslated into '\bind "<shortcut>" "<function>"'
and with the PrepareShortcuts-entry added to the active use file 'user.bind'
Function keys are sent to xvkbd as e.g. \[F15], so we should
not split a sequence like "\C\[F15]" into two text pieces.
(Do it like other keys not having a digit in their name (e.g. \[Return]) )
The controls are described in hello-world-in.txt as
Cr: not expected regex search pattern before next expected match
Cp: not expected search pattern before next expected match
See also findadv-re-04-in.txt for an example
In this test-case, searching for case sensitive and format considering
search is failing.
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.
