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.
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.
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.
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!
Using US english desktop language LyX's Mac OS adds some items to the view menu:
1. Show/Hide Tab Bar and
2. Enter Full Screen
These items won't work properly and it's better to hide them.
Mac OS adds two extra menu entries to the edit menu.
These menu items are:
1. Start Dictation...
2. Emoji & Symbols
Both menu items don't work with LyX.
Therefore they shouldn't be present and the new code hides them.
Both QTextLine::naturalTextWidth() and QTextLine::horizontalAdvance()
return the same value for \fint. However, examining esint10.ttf with
fontforge does not reveal any issue with the metrics. The fact that
\fint seems to be the only affected symbol might be due to its code
point, which corresponds to a space, so that maybe Qt makes some
assumptions on the metrics.
As QTextLine::naturalTextWidth() returns the width of the line that is
occupied by text, in the case of a single symbol we can obtain the
same value by using the width of the rectangle bounding the symbol.
Currently tested:
- url & doi fields for bibtex.
- all documented eprinttypes of biblatex
- absolute paths of first entry of 'file' field for jabref and kbibtex
- external script searching for author + year pdf
Additional polishing will follow.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg212505.html
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.
The 20px space on top and bottom of document have traditionally been
obtained by adding the to the ascent/descent of the first/last row.
This reads to annoyances like selections that are drawn in these
margins and issues with the nesting marker.
The change is to add the values to a separate member of the Row
object, and to add new Row::total(Ascent|Descent) methods that add the
effect of this padding.
Moreover, some methods are added to TextMetrics to simplify the
BufferView code.
Fixes bug #9545.
The old code in GuiPainter::filterColor did not work. Tricks with
colors should take place in HSV space, not RGB IMO.
Replace the code with a simpler one which maps the grayscale value
of the original color on the blend color. It works nin the case where
original color is red, but might not work as well when blend color is
not black. Time will tell.
Fixes bug #11904.
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.
It turns out that the resources were mostly not used anyway. Removing
them shrinks LyX binary by ~6MB.
Only autotools have been adapted. cmake will require the same
simplification.
The automatic icons for "command-alternative", "math-insert",
"math-(big)delim" and "command" can be overriden by an explicit icon
name.
Besides that, the iconName function is refactored, and now returns an
additional bool that indicates whether the icon should be flipped.
The code that uses resources is still useless. This will be the
subject of further work.
The code was checking only for particular vertical alignment requests
in order to decide to nest a standard array into a 1x1 ams matrix.
However, also vertical lines are not possible in ams matrices.
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.
