Despite being a 32-bit architecture, m68k has a basic
alignment of 16-bit for historic reasons. On m68k,
SAL_TYPES_ALIGNMENT8 is therefore equal to 2 and we
need to cover this case in the static asserts as well.
Change-Id: I4c756af25d57e5d49209697f6e678ef71a5845aa
Reviewed-on: https://gerrit.libreoffice.org/31878
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Failing to do that leads to write-past-end-of-document, drawing
loss and SAXParseException if the drawing is part of a footnote.
A unit test is included.
Change-Id: Ie7d8263dc72dfef1e9827cc0579a5eaaf5819410
Reviewed-on: https://gerrit.libreoffice.org/31871
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This appears to be a consequence of my change
commit 942716fee1
convert EID constants to typed_flags
in that change I made a "fix":
@@ -689,20 +687,20 @@ void
EventMultiplexer::Implementation::CallListeners (EventMultiplexerEvent&
rEv
ListenerList::const_iterator iListenerEnd
(aCopyListeners.end());
for (; iListener!=iListenerEnd; ++iListener)
{
- if ((iListener->second && rEvent.meEventId))
+ if (iListener->second & rEvent.meEventId)
iListener->first.Call(rEvent);
}
}
which causes this bug.
I should have noticed that my "fix" indicates that the event filtering
part of this multiplexing code was never working, and since no-one has
ever complained about, lets just remove all of this unnecessary
complexity.
Change-Id: Id71613d4fd5817ee1358705059e4ce63d57573ad
Reviewed-on: https://gerrit.libreoffice.org/31894
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
and
coverity#1397055 Inferred misuse of enum
copy and paste error from the other converted call site I bet
Change-Id: I63701db153c5fd424374a95dd757d9fd7a8bc216
regression from...
commit b894104a0b
Date: Thu Dec 8 00:43:09 2016 +0200
Pass GlyphItem around
We have this nice structure that contains (almost) all the information
we need, so pass it around instead of passing separate fragments of said
information.
presumably this is the correct fix given the context of the other changes
Change-Id: I8518e739b1caa00ea5ae1569282e98810462d4c3
...containing replacements for global operator new/delete (that can be linked
into executables), but which is no longer used. The mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2012-March/028690.html>
"operator new no longer routes through rtl_AllocMemory in libsalcpprt under
gbuild link rules" has the details of how this was used on some platforms (but
not on others) before the switch to gbuild, and has been "lost" ever since---but
apparently a loss not mourned much over the years.
For the SDK, c5f974287f "INTEGRATION: CWS jsc3:
#i62434# copy libsalcpprt.a" added the library (under Linux) and
6db9c5af96 "INTEGRATION: CWS jsc3: #i62434# extend
link options for executbales to link libsalcpprt.a, LINUX only" added its use to
odk/settings/settings.mk, but fc0ca57f2c
"INTEGRATION: CWS jsc21" removed that use again (for no documented reason). So
this is an incompatible change, but unlikely to actually affect any users of the
SDK.
Change-Id: Ia38b4c439f21fca3f5d9af7d1a34054e992054e9
Reviewed-on: https://gerrit.libreoffice.org/31810
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
and
coverity#1397040 Unchecked return value
coverity#1397047 Unchecked return value
coverity#1397049 Unchecked return value
coverity#1397050 Unchecked return value
coverity#1397051 Unchecked return value
Change-Id: Idf7dd7818b74c661a1f7a757f0bdc16e2d1d5c72
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>
This patch caused a regression that on creation of a new sheet
while there's an unfinished edit of a cell, by using "+" in bottom
left corner, that edit is committed to newly created sheet instead
of that in which it was performed.
Also, fixing original problem (tdf#42432), it forced the pending
edit on deleted page to go to an existing page, which could
overwrite existing data without being noticed (dataloss).
Reverting the patch does not reintroduce the original problem that
it intended to fix (a crash) in master.
Change-Id: I696a85ec9d08ebb3621ebdbce4d9f71eadcdb2c2
Reviewed-on: https://gerrit.libreoffice.org/31843
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
