Fix for bug #12547.
- "Interword" becomes "Normal"
- "Protected" becomes "Non-Breaking"
Plus a minor fixes to the "Horizontal Space Settings" dialog:
- Indicate that when "Non-Breaking" is disabled, the space will be non-breaking
Using the new inline statements
find_effective(), find_with_non_output(), find_with_deleted(),
find_set_feature(), find_add_feature() and find_clean_features()
makes the code a slightly better readable.
Also fix a thinko in interpreting the found values.
The match_len describes the length of the second regex field,
while matchend is the length of the search field 0.
Move the enum definition RowFlags in its own include file, to avoid
loading Inset.h. Document it more thoroughly.
Rename RowAfter to AlwaysBreakAfter.
Add CanBreakInside (rows that can be themselves broken). This allow to
differentiate elements before bodyPos() and allows to remove a
parameter to shortenIfNeeded().
Make the Inset::rowFlags() method return int instead of RowFlags, as
should be done for all the bitwise flags. Remove the hand-made bitwise
operators.
Set R::E::row_flags when creating elements.
* INSET elements use the inset's rowFLags();
* virtual element forbid breaking before them, and inherit the *After
flags from the previous element of the row;
* STRING elements usr CanBreakInside, except before bodyPos.
More stuff may be added later.
Add new RowFlags value CanBreakAfter, which says that the row can be
broken after the inset if needed. There is no CanBreakBefore yet,
because I do not know of an inset that needs it.
This makes screen closer to the actual behavior of insets.
Currently, only unprotected spaces and some special characters are
concerned. There may be more that need this handling.
Fixes bug #11621.
When several lines of text are in the same variable-width tabular
cell, it is not possible to align properly the rows until the cell
width is known.
Therefore a parameter is added to redoParagraph to skip this
computation, so that it can be done later in TextMetrics::metrics.
Other calls to redoParagraph in the code are not affected. It is not
clear at this point whether they may create artefacts.
computeRowMetrics has been renamed to setRowAlignment to better
reflect its use.
Fixes bug #11447.
It is a general problem when doing graphics to know where a line
begins and where it ends pixel-wise. At the instigation of Scott, and
with the use of the kmag magnifier, this commit corrects 3 areas:
* foreign marks were larger than the row element they were supposed to
mark. This could lead to moving lines, depending on paint ordering.
* visible spaces were drawn outside of their box (select a single
space to see this).
* the `L' blinking caret would leave a cursor dropping because the
horizontal part was too wide.
A basic class like Length should not depend on something from
frontend.
This change allows to remove several dummy implementations of
theFontMetrics().
This helper method is used to set the inset dimension cache at metrics
time. However this is already done by the metrics code itself
(MathRow::metrics, TextMetrics::redoParagraph), so that there is no
need to do this same work again in a different place.
Also, InsetPhantom::metrics is removed, since it does not do anything
interesting.
This commit comes with a mild risk attached (it might be that some of
these calls were useful after all!), but all of this is fixable.
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.
Use the function support:truncateWithEllipsis() to shorten a docstring with
... at the end. Actually we use U+2026 HORIZONTAL ELLIPSIS instead of "..." when
automatically shortening strings. This is to be consistent with Qt's own
truncation and is much nicer on the screen.
This includes the bugs #9575 and #9572 regarding broken text elision in the
outliner.
Known issues (non-regressions):
* TocBackend::updateItem() should be rewritten to update all TOCs. (#8386)
* "..." should be replaced with … everywhere else on the interface (including
translation strings).
* We should prefer to rely on QFontMetrics::elidedText() to truncate strings
with an ellipsis whenever possible, or an equivalent for the buffer view
dependent on the font metrics. See the warning in src/support/lstrings.h.
The computation of length on screen depend in particular of the computation of the size of an em. Many places of the code used to rely on the width of the M character, which is not really correct:
http://en.wikipedia.org/wiki/Em_%28typography%29
In digital typography, the best value to use is the point size of the font.
* Implement FontMetrics::em(), which returns the value in pixels of the EM unit.
Convert code to use it.
* Introduce Length::inPixel(MetricsBase const &), which takes the textwidth and em information from the MetricsBase object. Convert code to use it.
* Fix several places where Length::inPixel is used without a proper em value.
* add mathed_font_em() helper function. It should eventually be removed like some other functions in MathSupport.
* Add dummy implementation of FontMetrics to tex2lyx for linking purposes.
The main part of the fix (unicodesymbols) is from Jürgen. This commit fixes
tree problems:
- \; etc. were also used in text mode, but are math only
- all of those glyphs need to be forced with utf8
- actually, \; etc. are not the correct macros, since the encoded spaces are
breakable, but the math spaces are all protected. The sapce symbols are not
defined in the utf8 encodings.
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?
so we can write a limited amount when using this for TOC and
tooltip output.
This should solve the problem with slowness that Kornel noticed,
which was caused by our trying to write an entire plaintext
bibliography every time we updated the TOC. We did that because
he had a bibliography inside a branch, and we use plaintext for
creating the tooltip that goes with the branch list.
Other related bugs were fixed along the way. E.g., it turns out
that, if someone had an InsetInclude inside a branch, then we would
have been writing a *plaintext file* for that inset every time we
updated the TOC. I wonder if some of the other reports of slowness
we have received might be due to this kind of issue?
- \negmedspace and \negthickspace outside of math
- \enspace, \hspace*, \hspace*{\fill} and \hfill inside math
(fileformat change)
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@39557 a592a061-630c-0410-9148-cb99ea01b6c8
counting when exporting to latex. This is done for the code comprised
between \begin{document} and \end{document}, while the preamble code
still needs manual calls to TexRow::newline() for registering new lines.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37584 a592a061-630c-0410-9148-cb99ea01b6c8
blank lines may be inadvertently output. This is achieved by using two
special iomanip-like variables (breakln and safebreakln) in the lyx::
namespace. When they are inserted in the stream, a newline is output
only if not already at the beginning of a line. The difference between
breakln and safebreakln is that, if needed, the former outputs '\n'
and the latter "%\n".
In future, the new class will also be used for counting the number of
newlines issued. Even if the infractrure for doing that is already in
place, the counting is essentially still done the old way.
There are still places in the code where the functionality of the
class could be used, most probably. ATM, it is used for InsetTabular,
InsetListings, InsetFloat, and InsetText.
The Comment and GreyedOut insets required a special treatment and a
new InsetLayout parameter (Display) has been introduced. The default
for Display is "true", meaning that the corresponding latex
environment is of "display" type, i.e., it stands on its own, whereas
"false" means that the contents appear inline with the text. The
latter is the case for both Comment and GreyedOut insets.
Mostly, the only visible effects on latex exports should be the
disappearing of some redundant % chars and the appearing/disappearing
of null {} latex groups after a comment or lyxgreyedout environments
(they are related to the presence or absence of a space immediately
after those environments), as well as the fact that math environments
are now started on their own lines.
As a last thing, only the latex code between \begin{document} and
\end{document} goes through the new class, the preamble being directly
output through odocstream, as usual.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@37360 a592a061-630c-0410-9148-cb99ea01b6c8
that also makes sure it doesn't do more work than it needs to do, by
limiting the size to 40 characters. Previously, InsetBranch::addToToc()
would have added a string representing the entire contents of the
branch! It's hard to imagine that having to recalculate that sort of
thing doesn't cause some problems with speed, especially in documents
with lots of notes and branches and such.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36974 a592a061-630c-0410-9148-cb99ea01b6c8
