Age | Commit message (Collapse) | Author |
|
Change-Id: Ia6f79e50b93004b8bf896e24450ce8666b303037
Reviewed-on: https://gerrit.libreoffice.org/66856
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
...given that they get assigned with values of those types. This change has no
actual effect on the results, but silences Clang
-fsanitize=implicit-signed-integer-truncation warnings like "implicit conversion
from type 'long' of value -671088640 (64-bit, signed) to type 'sal_uInt32' (aka
'unsigned int') changed the value to 3623878656 (32-bit, unsigned)".
Change-Id: I763a9d85b9e40797312688551206c308fc3d36e3
Reviewed-on: https://gerrit.libreoffice.org/68705
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This change has no actual effect on the results, but silences benign Clang
-fsanitize=implicit-signed-integer-truncation warnings.
Change-Id: I0e96d998f9030c5bb4431dc0ccd689c8f2f3aeea
Reviewed-on: https://gerrit.libreoffice.org/68711
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This change does not change the actual results, but avoids Clang
-fsanitize=implicit-signed-integer-truncation warnings
Change-Id: If82193d7a6ad6bdadb4e8a8b3ed3bbdf3d88c4a3
Reviewed-on: https://gerrit.libreoffice.org/68706
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Regression from commit 8b73bafbc18acb4dd8911d2f2de8158d98eb6144
(tdf#115719 DOCX import: increase paragraph spacing for anchored
objects, 2018-02-14), which is an import-time workaround for a Word
layout bug.
Re-checking the original document from that bug, this only happens with
more anchored shapes (to the same paragraph), so make the workaround
condition more strict, fixing the layout of this bugdoc.
(Which means tdf115719.docx and tdf115719b.docx are modified to be more
close to the original bugdoc.)
Just checked, sadly Word's layout bug is still there in MSO 2019, so
can't revert our emulation of it (not yet).
Change-Id: I26f74a497b7718f8f3a2eadac481c8722e85e680
Reviewed-on: https://gerrit.libreoffice.org/68708
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: If9e6628ded7df0c822d57859e22a9a1e71d3c311
Reviewed-on: https://gerrit.libreoffice.org/68521
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Iec1ca76e9b3a0896a732ab2b7fd34dd5a7f219fb
Reviewed-on: https://gerrit.libreoffice.org/68367
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
For one, it that way matches reality (as it returns sal_uInt16, not short or
sal_Int16) and its SVBT32ToUInt32 counterpart. For another, I plan a follow-up
commit of introducing an additional SVBT16ToInt16 to explicitly return
sal_Int16.
Change-Id: I28915e6593ccdca0c11d7b2fa593e96e359a9532
Reviewed-on: https://gerrit.libreoffice.org/68686
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...so that running those tests with a read-only SRCDIR succeeds. (Needed to
move sc/qa/uitest/calc_tests/data/tdf76731.ods to fit the changes made to
sc/UITest_statistics.mk; all documents used by that test need to be at the same
place.)
Change-Id: I5c4a28539b9bacde3ca8983502ceed8e4688c787
Reviewed-on: https://gerrit.libreoffice.org/68683
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
At least during CppunitTest_sw_uwriter, some m_nStrResId is read so that Clang's
-fsanitize=implicit-signed-integer-truncation warned that an "implicit
conversion from type 'int' of value 74752 (32-bit, signed) to type 'sal_uInt16'
(aka 'unsigned short') changed the value to 9216 (16-bit, unsigned)".
Change-Id: I39f12d931bb18eea909494c8d7c9c0348fb71f27
Reviewed-on: https://gerrit.libreoffice.org/68664
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
No functional change offered, but this reduces some amount of confusion.
Japanese word "Katakana" ("kata" + "kana") does not undergo Rendaku [1]
while "Hiragana" ("hira" + "kana") does.
[1] https://en.wikipedia.org/wiki/Rendaku
Change-Id: I07824147d72397c312a0774eca1fdcc7549abc59
Reviewed-on: https://gerrit.libreoffice.org/68661
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Similar fix to b38065ea941375bf4f78f13314e84f4a875545d9
Only rely visibility setting for now, but properly:
visible means also printed, hidden means not printed.
Ie. import visible property also as printable, and only
output visible property in DOCX format (DOC shapes have no
such property).
Change-Id: Ifc3c36f90aa16ded1a9f31197612a5c85fde5d87
Reviewed-on: https://gerrit.libreoffice.org/68239
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
not adding any value
Change-Id: I8e7bc1150b4bf7e9431e522be3807007a52f65c4
Reviewed-on: https://gerrit.libreoffice.org/68667
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ibdc93b2afb3949fd25f14666f6eb3a4c1462f791
|
|
The problem is that when ToX is updated, CrossRefHeadingBookmarks will
be created for the heading nodes, and SwUndoInsBookmark will be created
at that time, but then nodes will be created for later entries in the
ToX and if the heading is below the ToX then the node index in
SwUndoInsBookmark will not match the node index of the
CrossRefHeadingBookmark.
Thus SwHistoryBookmark::IsEqualBookmark() will cause the mark to be
skipped during Undo instead of deleted, and then it can cause trouble.
Work around that by having SwHistoryBookmark::IsEqualBookmark() not
check the position if it's a CrossRefHeadingBookmark.
Change-Id: I9277978844837accdda35195a863c6163a839b6e
Reviewed-on: https://gerrit.libreoffice.org/68596
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
After fixing the infinite loop, the content of the merged table cell
with rowspan 3 is invisible, because its SwCellFrame and the SwRowFrame
containing it both have a height of 0.
This is due to funny code in SwTabFrame::Split(), which checks the bRet
flag before setting it to its final value, thus skipping the
lcl_AdjustRowSpanCells() call.
Change-Id: I96f9e9efdd5cae3a61da07995b8c31042fc59125
Reviewed-on: https://gerrit.libreoffice.org/68403
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
The bugdoc loops on calculating the follow of SwTextFrame 560, the one
containing "Hiermit nehme ich das Angebot an" in a cell with rowspan 3,
while the table is being split and its first row (also now its last
i.e. split row) is being formatted.
Loop in CalcFollow() because the follow is in the same upper frame as
its master and cannot move forward, so the 2nd call to pMyFollow->Calc()
after pMyFollow->Prepare() always sets the SetPrepWidows() flag on the
master and in that case the loop never terminates.
The problem is that the check in WidowsAndOrphans::FindWidows() of
GetThisLines() uses stale cached data - the value returned is 4, but
the frame contains fewer lines at that point and doesn't have lines to
spare for the follow; the cached value is only updated at the end of
SwTextFrame::Format(). Fix it by calling ChgThisLines() here.
But this fix only helps for the first SwTextFrame in a cell; the next
one with id 561 loops in a similar way. The problem then is that
SwTextFrame::PrepWidows() always calls SetPrepWidows(), even if the
Orphan-rule of the frame prevents it from giving lines to the follow.
Fix this by calling SetPrepWidows() only if lines are removed.
This also helps for the 2 attachments of tdf#118104.
(regression from commit 18765b9fa739337d2d891513f6e2fb7c3ce23b50
particularly the change in SwFrame::IsMoveable()
in the sense that it didn't loop before but there isn't anything
obviously wrong with this commit)
Change-Id: Ia1e5928a6510e68520b29eb265e26ffd0627c52e
Reviewed-on: https://gerrit.libreoffice.org/68402
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I993ee72f9e162a72b1d4e89d98763fe0d2dee4d4
Reviewed-on: https://gerrit.libreoffice.org/68662
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Ia8b07edec54527fb4904536fabb03a18e8452550
Reviewed-on: https://gerrit.libreoffice.org/68659
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 9865440d217d975206a3f91612f0666312bc8fd8.
This is not ready to land yet, seems like the latest update
of the logic reveals a bunch more places I need to fix before it can land.
|
|
verify that parameters use the exact same typedef-names (if any)
in definition and declaration
Change-Id: I55d2817f599b0253904dce2d35a1a93967e15a77
Reviewed-on: https://gerrit.libreoffice.org/68439
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
These are used for functionality that hasn't really been tested yet,
that I added right before moving on to other things last Spring, I
guess, which is why I hadn't noticed.
Change-Id: I1df26c5dff62269315b1a7eaaf574f7e38c452f6
|
|
Change-Id: Ie1e4a843e72351fabefba6f3a3c3fc9c35b40c46
Reviewed-on: https://gerrit.libreoffice.org/68606
Tested-by: Jenkins
Reviewed-by: andreas_kainz <kainz.a@gmail.com>
|
|
If the paragraph itself inherits BiDi from the environment,
this just means that it gets the value of the paragraph style.
If paraStyle is defined, then we don't need to spam the bidi
property, since it ought to naturally inherit it.
I can only see two possible problems. Either my logic is wrong,
or else import might not always take the paragraph style
into account (for determining the meaning of justify for example).
I want to start spamming justify in the case where the BiDi is not
specified but is inherited from the environment (page style
or AppLanguage). Separating this into multiple patches
will help for debugging in case of any regressive tendencies.
related to tdf#98620.
Change-Id: I36bc63e6659a4b491b5c6f2c99c72ba5bb715a07
Reviewed-on: https://gerrit.libreoffice.org/66921
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Instead of showing the tracked deletion as tracked
insertion, losing the original and actual text contents,
now w:del within w:ins is imported as tracked deletion
correctly.
Change-Id: I40694a3a73ad4cd443254167462520c17b1bd484
Reviewed-on: https://gerrit.libreoffice.org/68478
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ib3e9d0a7ff7e0fd3b0cf7bf492ca2bf59788fa2a
Reviewed-on: https://gerrit.libreoffice.org/68594
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
See http://bugs.documentfoundation.org/attachment.cgi?id=149585
+ https://bugs.documentfoundation.org/show_bug.cgi?id=123705#c4
Change-Id: I3c6fb0a1ac46a62c75bb9daeaded1633889416eb
Reviewed-on: https://gerrit.libreoffice.org/68398
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I5e46a88de2ff11ecd38667338b84babee24a2a11
Reviewed-on: https://gerrit.libreoffice.org/68591
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ie0fc6a6346f9c777b7172a0b641a2783cf633c1d
Reviewed-on: https://gerrit.libreoffice.org/68544
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
They had been added back in the day with
0c0c6f2727e2b0e954e5ab7afcafe6738ddb9e98 "INTEGRATION: CWS swwarnings"
(adressing "#i69287# warning-free code"), but don't seem to actually silence any
warnings, at least nowadays. Better to keep such narrowing casts implicit, so
that tools like Clang's -fsanitize=implicit-integer-truncation can detect cases
at runtime where a too-large value erroneously gets truncated by such a cast.
Change-Id: I3bba6fff034e544cd935c0c4dbc98989052add5e
Reviewed-on: https://gerrit.libreoffice.org/68541
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3ae15af8a2c7475394dfc5f6e54b89950d2238c0
Reviewed-on: https://gerrit.libreoffice.org/68511
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3759d4da18a7cb5a8fce500bd15e7a004e36c605
Reviewed-on: https://gerrit.libreoffice.org/68507
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
At least when CppunitTest_sw_filters_test tries to load
sw/qa/core/data/ww6/pass/crash-2.doc, Clang's
-fsanitize=implicit-signed-integer-truncation flags an "implicit conversion from
type 'unsigned int' of value 49197 (32-bit, unsigned) to type 'short' changed
the value to -16339 (16-bit, signed)" when multiplying nFSize by 10. That
document is obviously broken, LO emits lots of SAL_WARN like
"sw/source/filter/ww8/ww8scan.cxx:802: Unknown ww7- sprm, dangerous, report to
development", and at least MS Word for Mac Version 16.21 refuses to open it at
all. But even if the value of nFSize computed here is obviously way too large,
that variable is only passed into SvxFontHeightItem's sal_uLong nSz parameter,
so it can just as well be of type sal_uLong too.
Change-Id: I2e3b9152adce9c928df2276ebb2e9d526553e541
Reviewed-on: https://gerrit.libreoffice.org/68538
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0a62f2c03b5c8acef9d4231be1a1d5f0b83e81fb
Reviewed-on: https://gerrit.libreoffice.org/68501
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This patch replaces SwFEShell::SetTableStyle use to resolve tdf#108227
with SwTable::SetTableStyleName. The gain in insert speed is a result of
eliminating SwFEShell::SetTableStyle call to the time consuming
SwFEShell::UpdateTableStyleFormatting function which is somewhat
redundant when inserting a table.
Change-Id: Ide1e003d9709a6758e021b52fcf9e40a7b0fcba0
Reviewed-on: https://gerrit.libreoffice.org/68372
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Remove the Background tabpage in "Border/Background" dialog accessed
from Border and Background menu item in Header/Footer drop-down list
and replace it with the tabpages "Area" and "Transparency" of the dialog
accessed from Page Style > Header > "More.." button.
The old dialog does not have the tabpages "Area" and "Transparency".
In simpler words, the patch is to match both the dialogs
when accessed in two different ways.
Change-Id: Ib84435854389360eba41aecb8578a9a67a92ca1e
Reviewed-on: https://gerrit.libreoffice.org/67483
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
this is the single biggest chunk of stuff my upcoming paramtypedef
loplugin will warn about, so do it separately
Change-Id: I412e69e76406d6d947101885d4cd92c65e021508
Reviewed-on: https://gerrit.libreoffice.org/68486
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
m_nCurrentDataSet doesn't change, so it doesn't refill it, even
though m_nCurrentDataSet was deleted so it no refers to a new
entry
Change-Id: I0c68f407a23a28a7e55fb3cf691e5f07e5ed6729
Reviewed-on: https://gerrit.libreoffice.org/68497
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I5304e85cd3fd2edc48147f1297caa57417a3d038
Reviewed-on: https://gerrit.libreoffice.org/68496
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Extra style is causing editing problem near footnote/endnote
references. This behavior is a side effect of
eaa9cf6a3069fba3d82c046f0041bfb537d9e648, allowing emission
of these "technical" styles.
Change-Id: I1885b92814746e7b5cd19f3ddd7bc22eb691615e
Reviewed-on: https://gerrit.libreoffice.org/68304
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I18edeff43fcae98514c80d9f2c1594cc2f866e75
Reviewed-on: https://gerrit.libreoffice.org/68401
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I4477874116e8059cf0a82b9b3106c9e26a641947
Reviewed-on: https://gerrit.libreoffice.org/68400
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Given SwColumn::m_nWish is documented as "Desired width, borders included."
(sw/inc/fmtclds.hxx), it appears that the invariant
GetWishWidth() >= GetLeft() + GetRight()
should always hold for SwColumn instances.
However, during UITest_writer_tests4's test_tdf113284 loading of
sw/qa/uitest/writer_tests/data/tdf113284.odt, it appears that some five-column
table is created for which initially all SwColumns'
GetWishWidth() = 13107
GetLeft() = 144 (except for first SwColumn, where it's 0)
GetRight() = 144 (except for last SwColumn, where it's 0)
and later FitToActualSize is called reducing each SwColunn to
GetWishWidth() = 286
so that for most SwColumns (except first and last), GetLeft() + GetRight() = 288
would exceed GetWishWidth(). And then (still during loading of the test's
document), SwFormatCol::CalcPrtColWidth (sw/source/core/layout/atrfrm.cxx) is
called for such a problematic SwColumn, trying to subtract from its
GetWishWidth() (the result of SwFormatCol::CalcColWidth) both GetLeft() and
GetRight(), and store that into sal_uInt16 nRet. Which triggers Clang's
-fsanitize=implicit-signed-integer-truncation "runtime error: implicit
conversion from type 'int' of value -2 (32-bit, signed) to type 'sal_uInt16'
(aka 'unsigned short') changed the value to 65534 (16-bit, unsigned)".
So make sure that FitToAcutalSize upholds that presumed SwColumns invariant,
shrinking the borders as necessary.
Change-Id: I3f6fc07e65a0fc5d5f58c99f1dcdea4467b825f0
Reviewed-on: https://gerrit.libreoffice.org/68463
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Fix aVerticalLeftToRightBottomToTop:
- fnXDiff takes "logically larger, logically smaller" arguments, so it's
first - second for top to bottom text (existing directions) but it's
second - first for btlr
- fnXInc was effectively unused before, but it probably meant to provide
logical left + width, so set that to physical left - width for btlr
And then port 3 places in lcl_UpDown() to use aRectFnSet, so we get
correct behavior for both ttb and btt directions.
With this, pressing the left/right arrow jumps to the previous / next
paragraph correctly.
Change-Id: I1323e95e2ce0ab2d66a3ea6e02bd50df2cebf232
Reviewed-on: https://gerrit.libreoffice.org/68462
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I4b2dbd2446779e7179d2b79bf81cc2ff879377bf
Reviewed-on: https://gerrit.libreoffice.org/68389
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
like
bool Foo::bar() {
b = Super::bar();
return b;
}
Change-Id: I5e4c8005a3da7d7487c9039c35dcbb1d17e65bd7
Reviewed-on: https://gerrit.libreoffice.org/68418
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id4fbe6e16bb63e3df2768ce38161847ea6ff7eec
Reviewed-on: https://gerrit.libreoffice.org/68406
Tested-by: Jenkins
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@libreoffice.org>
|
|
Change-Id: Id6ac35fefa5c3e1f64c222713791e849b3cb4d34
Reviewed-on: https://gerrit.libreoffice.org/68379
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
fields private
Change-Id: Id3c6b123f06ab5dcf87628de4c347626110d2d27
Reviewed-on: https://gerrit.libreoffice.org/68302
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2476cbabbb3625ab0d562218102fbbcfbb08f4e6
Reviewed-on: https://gerrit.libreoffice.org/68404
Tested-by: Jenkins
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@libreoffice.org>
|