When implementing multi-row string breaking, an extra createLine()
statement, which made sense in the original code, was kept by mistake.
This basically made the mechanism ineffective, because it created one
row with the correct length, plus a second one with all the remaining
text, which would have to be itself broken. This went undetected
because the display is still correct.
Additionally, this issue polluted the break cache to the extent that
the hit rate could be 0%.
Together, these two effects created a major slowdown with a document
containing a single ~30000 characters paragraph.
Fixes bug #12534.
It is not a good idea to contruct a QChar from a char_type that is
really 32bits.
Use lyx::isSpace, which already catters for this case.
Since this code does not depend on qt anymore, move it to
support::countExpanders.
Get rid of Row::countSeparators, which is not used anymore.
Fixes bug #12519.
The string that Qt sees is not the original string, since we add
zero-width nonbreaking spaces around it, plus an override character to
force rendering direction. This means that translating positions
between these two representation can be a bit tricky.
We use a max(foo, 0) here to make sure that our intermediate
computation is postive.
Fixes part of bug #12452.
When a string is broken at the margin by the Qt algorithm, the space
at which breaking occurred is automatically skipped in width
computation. However, the ending space of the string is taken into
account and is visible for example at paragraph end.
When the trailing space is followed by a displayed inset, then the
space should be skipped too, which means that the width of the last
row element has to be recomputed. For the sake of performance, the
width of the element without trailing spaces is computed in advance in
FontMetrics::breakString.
This "no space" width will be used when trimming a row element of its trailing
spaces instead of the original one.
Additionally, do not trim trailing spaces when the row is flushed.
Fixes bug #12449.
Increase the maximal size of the breakString cache (to compute where
to break lines) from 512kB to 10MB. This has a big impact of cache
hits on large file like the example in #12297, which is now 99%. On
this example the time taken by breakString decreases from 33.5us to
2.4us.
The string width cache has been increased fro 512kB to 1MB, but this
does not make such a big difference.
Additionally, comments and variable names have been improved.
Related to bug #12297.
Replace FontMetrics::breakAt, which returned the next break point,
with FontMetrics::breakString, which returns a vector of break points.
To this end, an additional parameter gives the available width for
next rows.
Rename various variables and methods accordingly. Factor the code in
breakString_helper to be more manageable.
Adapt Row::Element::splitAt to return a bool on sucess and provide
remaining row elements in a vector. The width noted above has been
added as parameters.
Rename the helper function splitFrom to moveElements and rewrite the
code to be more efficient.
Remove type of row element INVALID, which is not needed anymore.
The code in TextMetrics::breakParagraph is now much simpler.
In Row::finalize, remove the code that computed inconditionnally the
current element size, and make sure that this width will be computed
in all code paths of Row::Element::splitAt.
In this case, the extra element returned should empty but valid. The
row flag BreakAfter is set to indicate that we have a break there
(this principle will be used more generally in a forthcoming commit).
To detect that we cut at the trailing space, it is necessary to rely
on the difference between QTextLine::horizontalAdvance() and
QTextLine::naturalTextWidth() when the flag
QTextOption::IncludeTrailingSpaces is used: the trailing space is
taken into account in the later, but not in the former.
Somme comments have been added to make code intent clearer.
At least with Qt 4.8.7 on Ubuntu 16.04, QTextLine::lineWidth() can
return a bogus value, at least with Courier font. One hypothesis is
that the invisible characters that we use in breakAt_helper are given
a non-null width.
Work around it, although the exact bug has not been pinpointed.
Since we intend to break the row element in two, it is not good to
truncate the string too early.
Moreover, the row element width is now set at this point, even if no
breaking occurs.
This fixes two performance issues and improves the performance of
TextMetrics::redoParagraph by 15% in a workload that uses the cache a
lot. The difference will be much less when the cache is not used much.
1/ repetion of the hash code computation
The code
if (cache.contains(key))
result = cache[key]:
is not efficient, since qHash(key) has to be computed twice.
To fix this a new Cache::object_str() method is added, which allows
if (auto * obj = cache.object(key))
result = *obj;
2/ code of has code computation
Instead of using a verbose string that is complicated to build as
key, new key structs BreakAtKey and TextLayoutKey are introduced,
along with the relevant qHash() implementation.
The method horizontalAdvance() replaces width() starting with Qt 5.11.
To handle this, all direct calls to QFontMetrics::width() are replaced
by calls to GuiFontMetrics::width(), and the code for
GuiFontMetrics::width(QChar) uses horizontalAdvance on newer Qt
versions.
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.
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.
Since be836909c52 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.
There are two techniques that I know of for forcing the direction of a
string, regardlessly of whether its contents is naturally LtR, RtL or
undecided.
1/ The unicode LTR/LTR override characters. This is supposed to be the
clean way, however, it does not seem to work with Qt 5.14 (see
#11691).
2/ The undocumented QTextLayout::setFlags method. This is used
internally and allows to pass the (undocumented) flags
Qt::TextForceRightToLeft and Qt::TextForceLeftToRight. This was
used until we had issues with Qt 5.11 (see #11284).
In order to get the best of both worlds, this patch allows to enable
those two methods separately, and actually enables both at the same
time by default!
(hopefully) Fixes bug #11691.
In particular, the directory frontends/qt4 is renamed to frontends/qt.
Many configurations file have to be updated. All mentions of qt4 in
the source have been audited, and changed to qt if necessary.
The only part that has not been updated is the CMake build system.
