It is not a good idea to call caretPosAndHeight when the caret is in a
paragraph that is not in cached metrics. This can happen when not
using "cursor follows scrollbar".
This commit refactor things a bit so that testing is done in
BufferView.
(cherry picked from commit e6b54ea4d2)
The rules for typesetting math differ from the rules for typesetting
text. For example, two italic 'f' chars have to be typeset more closely
than two 'o' chars in text mode, but not in math mode. Qt provides a
method that returns the distance appropriate for drawing a subsequent
character in text mode, but nothing for math mode. Typically, the
distance appropriate for drawing the next character in math mode is
the actual width span by the character, corrected by the rules of
an appendix in the TeXbook. Recently, those rules are followed more
closely in LyX but not exactly, and we have to find a way to adapt to them.
Some symbols may need more spacing around them than the width they span.
So, we use the distance suggested by Qt, unless it is less than the
width of the rectangle bounding the symbol. Before Qt 5.11 the used method
was QFontMetrics::width(), but since then it has been declared obsolete
in favor of QFontMetrics::horizontalAdvance(), whose name conveys better
its meaning.
No status entry is needed as this amends 79998fdc.
This restores the debug output as it was intended before the
introduction of the LYXERR macro that was unconditionally outputing
an end of line. This is how this output was appearing until lyx 1.5:
Looking for font family cmr10 ... got: cmr10
got it normal!
instead of as it was since lyx 1.6 and until now:
Looking for font family cmr10 ...
got: cmr10
got it
normal!
When the fonts distributed with texlive with same family name
as ours are also managed by fontconfig, Qt is not able to
discriminate ours by the style only. In order to be sure Qt
will load our fonts, we change the foundry name from 'PfEd'
to 'LyEd' and augment the font family name with this foundry
name. This only works on *nix, because adding a foundry name
seemingly breaks things on Windows. However, this is a *nix
only problem, seemingly.
Since be836909c5 the positioning of super- and subscripts
for symbol fonts has been broken because the metrics of the
font of the environment (rather than those of the symbol itself)
were used.
When running redoParagraph, it may happen that the ascent of the first
row changes. Since the ParagraphMetrics position is actually the
baseline of its first row, it may be necessary to update it.
Fixes bug #11601.
(cherry picked from commit 2e8c9cfc83)
This is a fixup to commit 611df441. It seems that the wrong unicode
property was selected. It could be that both classes should be used.
Fixes bug #11900.
(cherry picked from commit f758894c2f)
This commit adds the mathed command \mathds that selects a
font more appropriate than \mathbb for typesetting the
mathematical symbols for the natural (N), whole numbers (Z),
rational numbers (Q), real numbers (R), complex numbers (C),
and some others.
As in the \mathbb case, only capital letters are supported,
but in addition one can also typeset a symbol often used for
representing the indicator function (\mathds{1}) and the
letters a, h, k.
Fixes bug #11887.
The above mentionned patch did paint the background of the sublabel to
avoid "bold-like" effect. However the correct backgound color is the
row's one, not the inset's one.
To fix this, extend MetricsInfo::backgroundColor to work when no inset
is specified. The code is also simplified as in master.
(cherry picked from commit 74540c9896)
(cherry picked from commit a71b96ac42)
note-next and reference-next should trigger an update so that metrics
are updated when the cursor ends up in an auto-open inset.
Fixes bug #11870.
(cherry picked from commit 7761e1317e)
Before, we would continually set the selection to the empty string,
to maintain ownership. This causes problems with clipboard managers
GPaste and CopyQ. Further, in theory this should have better
performance since checking ownership should be faster than setting.
A disadvantage of this change is that the timestamp of the selection
will be old at this point in the code. However, when the selection
is requested, we put the selection contents at that point so the
selection timestamp should be accurate then. Further, the selection
contents are not accurate at this point in the code (they are just
the empty string), so it is not clear whether having an accurate
timestamp is beneficial.
Fixes#11715.
(cherry picked from commit af4ee1a487)
(cherry picked from commit 23abb5aaa3)
