theorem environments what the already existing "by chapter" modules
do for non-AMS ones.
(cherry picked from commit 0f5ba65eae1b3e069be0be279904c911fe02907c)
An overlong word containing a hyphen could be broken anywhere, instead of after
the hyphen.
Example: compare the line breaking of
aaaaa-aaaaa-aaaaa-aaaaa
with
aaa aaaaa-aaaaa-aaaaa-aaaaa
(with a very narrow window)
This also improves Chinese text in some situations (#10299)
(cherry picked from commit 50ccbd2eab8cb01ff9f7c80d3fe726297dca6fae)
Showing deleted display math by enabling "Show Changes in Output" was
only possible with dvi (through dvipost). Although LyX strikes out
such formulas on screen, it was impossible obtaining an output
directly using pdflatex (or other engines producing pdf) because
ulem cannot cope with display math material and gives errors.
The solution is to strike out by ourselves such deleted formulas.
I took into account several options. One of them would produce
an output similar to dvipost (which strikes out each element), but
would have required much more changes in the output routines.
Eventually, I opted for using tikz, which gives a more clean
output (as it requires to simply adding a preamble and a postamble
to the latex code of any displayed math, instead of a mark up
tailored to each particular math construct). The look of the pdf
output is similar to the way LyX strikes out the equations on screen.
Fixes#9678
This is analogous to what has been done to address #4889 and #10359.
Fixes bug #10475.
(cherry picked from commit d207e85cfda2893de4e6c7f419c58aa342395f47)
It turns out that Cursor::getFont() does not return a fully realized
font in some cases. This patch uses real_current_font instead, which
seems better anyway.
I suspect that all uses of getFont() should be removed, but this is
not code that I know well.
Fixes bug #10478.
(cherry picked from commit b099d9ae15c45a9c30727078d69c0c7bd8029c9a)
This means that, when a string contains high-plane Unicode characters,
the length of a docstring and the corresponding QString will be
different: Qt will encode these characters using several 16bit
characters.
We have additionally to take into account QTBUG-25536, which implies
that sometimes qstring_to_ucs4(toqstr(s)) !=s. It is not clear whether
this bug can be a problem in other places.
Fixes bug #10443.
(cherry picked from commit 5d85a42bf0a182585b800a80817a6e1208ef7ec3)
1. We must always output all (diverging) options, including
default options; if not, default options might get overwritten.
2. Do not output options in \setotherlanguage, since we might have
multiple "other languages" varieties from the same language (such
as naustrian, nswissgerman). And the options are output for the
language switches anyway.
Hence, LaTeXFeatures::getPolyglossiaLanguages() does not have to record
varieties. This was not done correctly anyway, since the map allowed
for one entry per language only.
The code is much simpler now and can be actually understood.
As a byproduct, fix bug #10424.
(cherry picked from commit a700d657b3b06541b10ddae8cc5847bd46d06aae)
(cherry picked from commit 2037cc5ef575f134de2790eda299e7becb2c5a01)
(cherry picked from commit 4159cf97c156ea2f604e3332fc2bf4d1c4926a25)
(cherry picked from commit 695b0cc33b04fa10c8134738e4726de5336267f4)
When using polyglossia, lyx was making a real mess when changing
language inside nested insets. The \begin{language} and
\end{language} commands were not well paired such that they could
easily occur just before and after the start or end of an
environment. Of course this was causing latex errors such that
"\begin{otherlanguage} ended by \end{environment}".
Fixes#9633
Single quotes are special to our parser and must be either escaped or
quoted if they are part of a filename, otherwise they are stripped out.
Fixes#10342.
This fixes two particular problems
* with Qt5, it seems that QFontMetrics::width does not return the
correct value for some Arabic text; this patch uses QTextLayout
instead to compute a string width
* Likewise, the undocumented layout flags TextForceRightToLeft and
TextForceLeftToRight do not work with Arabic text; this patch uses
unicode override characters instead.
It might be that the two issues are related. In any case, they do not
happen with latin text where right-to-left direction is enforced. And
they do not happen with Qt4.
Additionally, remove some dead code in GuiFontMetrics::pos2x().
Fixes bug #10436.
(cherry picked from commit e832d2e90f300afb1b1255a486e56d059b2dfab7)
