Age | Commit message (Collapse) | Author | Files | Lines |
|
... undeletable page
(cherry picked from commit 0005b330eaed0b5559042d2597fb45e0c9125d7e)
Conflicts:
sw/qa/extras/layout/layout.cxx
Change-Id: I4622569eb9c757c6dcbdda32081ddc94e53db919
Reviewed-on: https://gerrit.libreoffice.org/66393
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 558f01a29cb640760e73724f6efdc0a1be20c8e3)
|
|
A row frame may not belong to a table frame, when it is being cut, e.g., in
lcl_PostprocessRowsInCells().
Its SwRowFrame::Cut() has been called; it in turn called SwLayoutFrame::Cut(),
which nullified row's upper in RemoveFromLayout(), and then called Shrink()
for its former upper.
Regardless of whether it will be pasted back, or destroyed, currently it's not
part of layout, and its height does not count.
See bt https://bugs.documentfoundation.org/attachment.cgi?id=139171
Change-Id: I4010e1f246a3ebb89b3f972a03619a2775146da4
(cherry picked from commit daf1b10f4e266818b6e14f0f1dfddd66f0a3a2f0)
Reviewed-on: https://gerrit.libreoffice.org/48234
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Crashed in a11y code with a SwFootnoteFrame that survived a JoinNode and
subsequent deletion of its reference-containing SwTextFrame and thus had
a stale "pRef" member; presumably the SwTableFrame needs to delete an
empty footnote frame like the SwTextFrame does from SwContentFrame::Cut(),
called from DelFrames(), called from CutImpl().
Change-Id: I5a30357ecd3bf474bfc4a5451de89beb245fb0ae
|
|
Change-Id: I604aa74e737894daa6e1878ac3ed61d9eeb6512a
Reviewed-on: https://gerrit.libreoffice.org/37296
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
git grep -l "[ _\.]THROUGHT" | xargs sed -i 's/THROUGHT/THROUGH/g'
git grep -l -i "[ _\.]THROUGHT" | xargs sed -i 's/throught/through/g'
In ENUMs: THROUGHT = THROUGH (preserved as valid alternate spelling)
In ooxmlexport8 - unit test confirms THROUGH = THROUGHT
Change-Id: Iae0fef9a8adcb96761989f38903a24ffb1b91e77
Reviewed-on: https://gerrit.libreoffice.org/35998
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Translate German comments and terms in sw/inc/ and sw/source
Change-Id: I1330a358db2c6cdc0512009befeafa0582ac4877
Reviewed-on: https://gerrit.libreoffice.org/36288
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ia87318cb323d403cdff947da0b70e0d2aabaacd4
Reviewed-on: https://gerrit.libreoffice.org/35657
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I029ad67dfcbc40f3953adf485957efcbd97f23d0
Reviewed-on: https://gerrit.libreoffice.org/35328
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8afde16343288888d9b1806fae6cba3514812d02
Reviewed-on: https://gerrit.libreoffice.org/35062
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ib725427225fe95fb39a72f96bbd60d5464c9351a
Reviewed-on: https://gerrit.libreoffice.org/34782
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
no point in redeclaring an existing enum exactly
Change-Id: I4fb367e4b27e36601f1f36b629097a87b5f00096
Reviewed-on: https://gerrit.libreoffice.org/34773
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iaf6bbe81f519d49b82f624282d786c8cc18d641c
Reviewed-on: https://gerrit.libreoffice.org/34199
Reviewed-by: Aleksandar Stefanović <theonewithideas@gmail.com>
Tested-by: Aleksandar Stefanović <theonewithideas@gmail.com>
|
|
Change-Id: If850989ee513d29ed373df0c6dd9905ec694026c
|
|
The problem seems to be the table's repeated rows value which is
setted to max table rows in some docx file.
Decreasing repeated rows value by one avoids loops but renders a bad
layout.
Table continuity is lost and lots of rows are hidden.
So I set repeated rows value directly to one in order to avoid bad
layout.
Change-Id: If4adc33febe088a866b704e87e49339710e5aaf5
Reviewed-on: https://gerrit.libreoffice.org/32349
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
|
|
This solves the problem of rows with too big minimal height causing
layout failure (the table just goes out of page, does not flow to
next page).
It does so with three steps:
1. Currently, a row with a minimum height that flows to next page
repeats whole min height on that (and possibly following) pages.
If this behaviour continued, then that would cause layout loop:
the row min height would be too high for the page, so it would
keep flowing to next pages (actually just go beyond the botom
because of layout failure). To mitigate this, the patch changes
the behaviour to measure total height of all frames of the row:
the function lcl_calcHeightOfRowBeforeThisFrame calculates the
total height of previous row frames for the same row, then in
places where we need to get min height, this value is subtracted
from row min total height. On following pages the min height of
frames will get less each time.
2. When the row is split, the possibility to split depends on if
the minimum height of the row fits into the vertical space left.
The minimum height is found as maxinum of two values: minimal
contents of the row (e.g., height of first line of text, or an
object, or lower table cell), and the minimum height setting.
As the minimum height setting should not prevent the cell to
flow, (it only should ensure that total height is no less), we
should not consider the setting when the split is performed
(we should be able to keep on first page as little as required).
To allow this, a new bool member introduced in SwRowFrame:
m_bIsInSplit, with its setter and getter. When it is true,
the routines that calculate min height ignore the min height
setting. It is set in lcl_RecalcSplitLine around lcl_RecalcRow
and SwRowFrame::Calc that decide if it's possible to keep part of
row's content on first page, and update table's height to fit
the rest of space.
3. It turns out, that if contents of the splitted cell has less
height than the min height setting, then following happens.
In SwTabFrame::Split, all rows below splitted one are moved to
follow flow table; then table frame's Shrink method used to shrink
the freed height. At this moment, still, the height of splitted
row is too high, and total height of table is too high. Then,
lcl_RecalcSplitLine is called, where row is first shrunk, and then
lcl_RecalcRow and SwRowFrame::Calc try to move contents and resize
the splitted row. They get the minimum height of content (we already
don't consider the min height setting), but then "last row will fill
the space in its upper" (see SwRowFrame::Format). Row returns its
previous size, table does not resize, it doesn't fit to page, and
split fails.
To try to fix that, I call SwTabFrame::Shrink in lcl_RecalcSplitLine
after lcl_ShrinkCellsAndAllContent before lcl_RecalcRow.
Unit test included.
Change-Id: I8422e43cff7d6b5955541ed3fe930779429ed55b
Reviewed-on: https://gerrit.libreoffice.org/31774
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I700e51dbfe0768642d482556299407f8f198e998
Reviewed-on: https://gerrit.libreoffice.org/31709
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Cf. comment for #i2109 in commit 90b73c7b
Change-Id: I74a606d0c5c6e1071e914b4565d825920c71d158
Reviewed-on: https://gerrit.libreoffice.org/31626
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I288c5125a1316828df74f73aeaac85392638ffd8
|
|
Change-Id: Iced8ff99d52d55e6b6c3126affafbea6786e94f0
Reviewed-on: https://gerrit.libreoffice.org/30858
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia59d287a015482e9e97b701a6695463a7d235203
Reviewed-on: https://gerrit.libreoffice.org/29439
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: Ib400c5930be84d26665b0e12a61508c8fbfd7f08
Reviewed-on: https://gerrit.libreoffice.org/29105
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
regression from...
commit 15d8b51bf82610c663f80fe552a1c0315e137ad3
Author: Caolán McNamara <caolanm@redhat.com>
Date: Tue Feb 5 17:33:49 2013 +0000
Resolves: rhbz#907933 crash on removing second last para in cell...
if (basically) the last para is on next page
so revert that and try a different fix which now works to keep the original
problem crash-free and fix this one too
Change-Id: Ia6b3ef48c43ceceb7ee7cc2b8b803314349f3785
|
|
Change-Id: I09c1ebaf5742e983ee05942a4c7c17c6aa5179cc
|
|
Change-Id: I52a4cf0732240aa26147313ae6a52c4fd8d8933c
|
|
Change-Id: I68ec79c9c85abcd91da379eecf3ed4331a15861b
|
|
Change-Id: I7aaa5c45a224d2f97861864bed00eaddb9b7f317
|
|
Change-Id: I1f4a0ad6658bd3154c48940296aa8edc1ea1612c
Reviewed-on: https://gerrit.libreoffice.org/24876
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
|
|
Change-Id: I27ff0f4f0eb395d7e0a60dd604758c220a3134c4
|
|
Change-Id: I785d154a5df9a33b7d513dee1d3d859e5e800e7a
|
|
Commit b4b5dbee1ec7770ed64d7270de46d5cfc06b87b6 (tdf#88453 sw layout:
fix split of nested tables with large amount of rows, 2016-03-23) took
care of two similar problems when splitting tables which has nested
ones (setting cell height to 0 when its content height is 0, and setting
row height to 0 when its cells' height are zero).
Turns out there is a third aspect of the same problem: when row heights
are set to 0 during shrinking for table split purposes, the table height
has to be set to 0 as well, in case the table contains only 0-height
rows. With this, the original bugdoc's layout is the expected one.
Change-Id: I3f5392eb914a60e9caa5182dc6d44bd3a93f41d6
Reviewed-on: https://gerrit.libreoffice.org/23497
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
This does not fix the original bugdoc, just the case described in
comment 2. The bugdoc has an outer table of a single cell, and that cell
has a nested table with a single column and many rows.
When we split the table, we set the height of the last row frame to
zero, then the height of the last but one, and so on, till the reduced
table fits the page, then move the 0-height frames to the next page, and
so on. All this recursively, to support nested tables.
The problem is that 0-height is set only for the contents of the cell
frames, but not for the cell or row frames themselves, so in case e.g.
the default ~0.10cm inner margin of the cell frames, even a 0-height
text frame results in a cell frame height of 111 twips. And this error
can accumlate if there are enough rows, e.g. with the default fonts 123
rows are enough to trigger the situation when even a completely reduced
table doesn't fit the first page frame, and the layout throws up its
hands.
Fix the problem by setting the height of the cell and row frames to 0 as
well in case their content is 0-sized anyway (so a re-format will later
restore their correct height).
Change-Id: Iefbbb7bd6ef97a9a81929eb2599adb961e52fd38
Reviewed-on: https://gerrit.libreoffice.org/23476
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I56925a8fd776b3ee787cc26adbaa08c58dd022c0
|
|
connect table with the following paragraph. Move forward to a new page
together with the following paragraph if necessary.
Most of the added code allows the table to split if
all of the kept items do not fit on one page - allowing
the emulated table to match the layout of kept tables.
The only difference with .doc occurs when the table itself is larger
than one page. In that case it ALWAYS starts a new page. Although
it does not match .odt, it DOES match how MSWord handles that .doc.
Change-Id: Ic6f495c0dc5cd4e9f8029a8cec9e31b4fab4b20f
Reviewed-on: https://gerrit.libreoffice.org/20233
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86
Reviewed-on: https://gerrit.libreoffice.org/21209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Removing an old hack that is no longer needed.
A table marked as “keep with next” doesn't split and keeps with the
following paragraph already. It doesn't require this old hack to
function properly anymore.
Preventing tables from splitting had forced
large tables to always start on a new page. Removing the hack
allows everything to lay out nicely now. There is a fairly large
suite of tests in the bug report that prove the proper layout of
various keep-with-next situations.
Any document depending on the old behaviour can simply (and properly)
insert a manual page-break before the table in order to force it to start
on a new page.
Change-Id: Ie2036c1a638009aaf95247574998077a1e55b5e5
Reviewed-on: https://gerrit.libreoffice.org/20216
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
This commit renames the most annoying abbreviations in Writer (and
partially in the shared code too).
Change-Id: I77e5134f42f25e3786afa36b7a505c7e3237a9e8
|
|
Change-Id: I6f4d0bb57c5d82984ff29b621dc4570f453be31d
|
|
Change-Id: I01e11fa956a249974e77dce9deebe79311f098d0
|
|
The short-lived SwBorderAttrAccess is manually deleted
which is not exception safe and can potentially leak.
This wraps it in unique_ptr.
Change-Id: Ib45c1c36214583e0bf205231f9f793e023d106c7
Reviewed-on: https://gerrit.libreoffice.org/19701
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I11ff551955c1ac291ab576f2f18c2dd410427eda
|
|
Change-Id: Ib5b0e87064b6dcff03f6b77287a80ee2a03b8799
|
|
replaced use of PTR_CAST, IS_TYPE, ISA in
idl, editeng, sc, sd, sw, sfx2, sot, starmath
Change-Id: I4a5bba4fdc4829099618c09b690c83f876a3d653
Reviewed-on: https://gerrit.libreoffice.org/19132
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Oliver Specht <oliver.specht@cib.de>
|
|
Change-Id: I85e0c180df952c51b537b5408653160aad8b9a32
Reviewed-on: https://gerrit.libreoffice.org/18986
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Sun bug numbers without any accompanying text are completely useless.
Fixed with
git grep -lP '//\s*#\d+#\s*$'
| xargs perl -i -ne'/\/\/\s*#\d+#\s*$/d or print'
And then hand-checking the result to restore places where it deleted code.
And then some more grepping and hand-editing to kill the others.
Change-Id: Ia96ce4466db8bb8da363ebf41f0ae7f45f28bf29
Reviewed-on: https://gerrit.libreoffice.org/19023
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ic2cb2c4d9534d503828308183d55cea5b8d88112
|
|
Change-Id: I2f1f7609e9ceed3804be76775eeebcddd9e443c6
Reviewed-on: https://gerrit.libreoffice.org/17462
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
KeepWithNext shouldn't be applied to nested tables
Change-Id: I6df002ae7b00afa0fcf82aab584f85d9a47315eb
Reviewed-on: https://gerrit.libreoffice.org/15794
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I1b510a6194282dfa4a9001d473127c5ebc8b44eb
Reviewed-on: https://gerrit.libreoffice.org/16731
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Id9296115f30858e7fd470a199e59343a96d7deec
Reviewed-on: https://gerrit.libreoffice.org/16712
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <s.mehrbrodt@gmail.com>
|