Fixes for bug #11428. Emphasis is used regularly and it is helpful to
see whether the next text will be written emphasized directly from the
cursor.
This is also implemented in MS Word and Google docs but not in
LibreWriter.
Also fixes the caret for RTL languages whose width was previously
extended into the wrong direction.
Set fonts to DejaVu to avoid the following error:
! Package polyglossia Error: The current latin font does not
contain the "Cyrillic" script!
This choice of font is consistent with the Russian intro and
tutorial manuals.
The change includes a rewrite of the cursor movement when „mac style“ is enabled and don’t change anything otherwise.
The new code for mac uses the document iterator to go forward or backward. The traversal stops at word boundaries.
If going forward the position increments until a word is reached (if not already inside) and stops at the end of the word.
If going backward it does the same in opposite direction. The cursor jumps over non-editable insets and math.
Editable (open) insets are entered and the cursor move detects word boundaries inside them.
These exports now pass, and the output looks reasonable to me
(although I do not know Hebrew). I believe they work now because of
Jürgen's fixes at a7ad0747 and d7b64b8e.
Instead of working around crashes in update of caret geometry, only
request it as needed. The actual computation will take place just
before painting the caret.
It might be that this is overkill and that caret geometry should be
updated unconditionally. One would have to to some timing while idle to
ascertain that.
Fixes bug #11912.
The macros defined in the symbols file are only used for on-screen
representation, so that their definition should not require the use
on any latex package. Their definition should be taken into account
only when they are overridden by user macros with same name.
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.
Previously there are po-entries like
#: lib/examples/Articles:0 src/TocBackend.cpp:296
#:src/frontends/qt/GuiExternal.cpp:87
msgid "External Material"
msgstr ""
now:
#: src/TocBackend.cpp:296 src/frontends/qt/GuiExternal.cpp:87
#: lib/examples/Articles:0
msgid "External Material"
msgstr ""
(The string at 'lib/examples/Articles:0' proceeds also from the directory name 'lib/examples/External_Material')
This makes it easier to use some po-editors like 'linguist'
Instead of working around crashes in update of caret geometry, only
request it as needed. The actual computaiton will take place just
before painting the caret.
It might be that this is overkill and that caret geometry should be
updated unconditionally. One would have to to some timing while idle to
ascertain that.
Fixes bug #11912.
Move InsetMacro::limits_ to InsetMacro::Private, where it should have
been from the start. This means that limits_ is now copied when the
macro is cloned.
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.
