This computation did not make sense anymore since we began to put the
contents in the Row object. The fact that it worked was a coincidence.
Instead, we set rows as changed() on creation and reset that once they
have been drawn. This will allow in the future for a finer definition
of what to redraw or not.
Also update the PAINTING_ANALYSIS document
The computation of the legth of expanded hfills did not take into account their unexpanded size. This is done now by increasing the dimension (+=) instead of merely setting it.
Moreover, since the insets sizes are integer number, rounding effects have to be taken in account. To this end, the extra number of pixels is added to the last hfill in the row.
This fixes part of bug #9860.
Note not everything is fixed by this patch: the logic of ParagraphMetrics::hfillExpansion seems bogus to me. I do not see why consecutive hfills at the beginning of a row should not be all expanded. Since I do not know what are the peculiarities of hfill handling in LaTeX, I did not change it (yet).
I did not either try to investigate the label hfill part, because I do not even know what is so special about it. I think there is a lot of old logic that nobody ever tried to question.
We already have a CoordCache of insets dimensions. It is not necessary
to store the same information in two places.
Give a name to CoordCache tables types to improve code readability.
Remove ParagraphMetrics::singleWidth, which is not used anymore.
The symptoms are the same as the original #9224, but the reason is different. In the new code, the width of justified rows includes the Row::separator value. Therefore the CRC computed in ParagrahMetrics::computeRowSignature is not updated in some cases.
The fix is to add Row::separator as one of the elements of the row crc.
This is handled by Qt now.
Note that a small optimization (do not draw text that is to the left
of WorkArea) is removed because it cannot be guaranteed to be exact
anymore. It was probably not very useful anyway, and would become
useless once the RowPainter is rewritten to use Row information.
Update 00README_STR_METRICS_BRANCH.
* Row now contains a vector of Elements
* replace Row::dump by a proper << operator
* the width is updated as elements are added
* breakRow is reimplmented to use this infrastructure
The algorithm used for breaking a paragraph in LaTeX export is changed
for avoiding spurious blank lines causing too much vertical space.
This change is tied to the introduction of a new inset (with two
different specializations) helping in either outputing LaTeX paragraph
breaks or separating environments in LyX. Both of the above goals were
previously achieved by the ---Separator--- layout and can now be
accomplished by the new inset in a more natural way. As an example,
after leaving an environment by hitting the Return key for two times,
a third return automatically inserts a parbreak inset, which is
equivalent to the old separator layout, i.e., it also introduces a
blank line in the output. If this blank line is not wanted, the
parbreak separator can be changed to a plain separator by a right
click of the mouse. Of course, an environment can still be separated
by the following one by using the Alt+P+Return shortcut (or the
corresponding menu key), but now the plain separator inset is used
instead of the old separator layout, such that no blank line occurs in
the LaTeX output.
Old documents are converted such that the LaTeX output remains unchanged.
As a result of this conversion, the old separator layout is replaced by
the new parbreak inset, which may also appear in places where the old
algorithm was introducing blank lines while the new one is not.
Note that not all blank lines were actually affecting the LaTeX output,
because a blank line is simply ignored by the TeX engine when it occurs
in the so called "vertical mode" (e.g., after an alignment environment).
The old ---Separator--- layout is now gone and old layout files using it
are also automatically converted.
Round trip conversions between old and new format should leave a document
unchanged. This means that the new behavior about paragraph breaking is
not "carried back" to the old format. Indeed, this would need introducing
special LaTeX commands in ERT that would accumulate in roundtrip
conversions, horribly cluttering the document. So, when converting a
modified document to old formats, the LaTeX output may slightly differ in
vertical spacing if the document is processed by an old version of LyX.
In other words, forward compatibility is guaranteed, but not backwards.
each failure.
There are several places I was not sure what to do. These are marked
by comments beginning "LASSERT:" so they can be found easily. At the
moment, they are at:
Author.cpp:105: // LASSERT: What should we do here?
Author.cpp:121: // LASSERT: What should we do here?
Buffer.cpp:4525: // LASSERT: Is it safe to continue here, or should we just return?
Cursor.cpp:345: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:403: // LASSERT: Is it safe to continue here, or should we return?
Cursor.cpp:1143: // LASSERT: There have been several bugs around this code, that seem
CursorSlice.cpp:83: // LASSERT: This should only ever be called from an InsetMath.
CursorSlice.cpp:92: // LASSERT: This should only ever be called from an InsetMath.
LayoutFile.cpp:303: // LASSERT: Why would this fail?
Text.cpp:995: // LASSERT: Is it safe to continue here?
Gcc 4.7 warns that this kind of narrowing is illegal in C++11, so
we can just as well fix that right now.
In GuiFontMetrics this is fixed by chaning the types in the AscendDescend struct
from short int to int.
In ParagraphMetrics it is fixed by addint explicit casts.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@40586 a592a061-630c-0410-9148-cb99ea01b6c8
- Interpret argument of LFUN_SPACE_INSERT correctly
- Use InsetMathSpace instead of InsetMathSpecialChar for "\ " (bug # 7728)
- Use InsetMathSpace instead of InsetMathChar for ~ (bug # 7728).
This fixes also the display in LyX (previously a literal ~ was displayed).
Using InsetMathSpace enables also the "Insert Formatting" menu entries.
No file format change is needed, since the LaTeX export is unchanged.
Note that there are still some bugs related to spaces in math:
#7746, #7747, #7749, #7842
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39947 a592a061-630c-0410-9148-cb99ea01b6c8
Solution: don't use boost::bind for msvc10 (could also be extended to several GCC versions)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@34257 a592a061-630c-0410-9148-cb99ea01b6c8
1. When a listing is inserted in a bit of text, the line above the listing is not drawn over the full width like it is done for lines above other insets. This is because InsetListing has a AlignLeft alignment. Now, if you start selecting downwards with the mouse in this empty area, strange selection drawings appear (see attachment).
This is caused by the fact that starting your selection at such a place, causes beg.boundary() to be true in TextMetrics::drawRowSelection(..). This is correct, but this value is true for _all_ selected lines. Now, the selection acts as if it is RTL text. Therefore, just like for end.boundary, this value needs to be reset for every line.
2. Starting your selection in an end margin often causes the selection in this end margin to be painted later. This is because when starting your selection in an end margin, you may have set a (possible empty) selection before really selecting the end margin. The problem is that the checksum (computed later) is the same for this empty selection and for the end margin selection. Therfore, we need a call to cur.setSelection() before evaluating cur.selection().
3. In the following two lines, it is assumed that there is only an end margin to be painted if the selection extends to the next paragraph. This is not true for the above described case of an AlignLeft Inset. Then, the margin has also be drawn within a paragraph
4. The end and begin margins are only painted when the selection extends into the following or previous paragraph. This difference is not resembled in the checksum if you first select a row completely and then procede to the next or previous paragraph as the selection remains at the end of a row. This also holds for the AlignLeft case. Therefore I added a term to the checksum to monitor whether the end and begin margins need to be drawn.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@26399 a592a061-630c-0410-9148-cb99ea01b6c8
The need for a LayoutPtr arises from the fact that (a) we do not want to give our clients a Layout &, since we do not want them to be able to change our Layout; but (b) we also need to be able to change which layout is ours. So we cannot store a Layout const &. Or so it seems to the compiler.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23522 a592a061-630c-0410-9148-cb99ea01b6c8
Sorry, Andre, but this broke not only the modules stuff but the general handling of TextClasses. I'm not opposed to doing this sort of thing, but it's going to be a little more complicated. I'll do it when I get a bit of time, or I can explain what the issue is here if you want to do it.
I'll separately re-commit some of the cleanup here.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23189 a592a061-630c-0410-9148-cb99ea01b6c8
Also a few cosmetical changes where I xould not resist.
Would be nice if the 'modules people' could verify that their baby
is strill alive...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23154 a592a061-630c-0410-9148-cb99ea01b6c8
Now support/* should have no dependencies on src/* anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@21851 a592a061-630c-0410-9148-cb99ea01b6c8
