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 18765b9fa7
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>
The patch covers several errors, see comments in the bug report.
Change-Id: I6cdaf3e8951dab21b314ef61e12ffa3b3ee481dc
Reviewed-on: https://gerrit.libreoffice.org/68029
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
most of the time shapes have generated names such as 'Shape 42', those
have ~no added value so let's not include them in Alt text
Change-Id: I30314d5e901e11722e609dbf7ceddf74c5ed9707
Reviewed-on: https://gerrit.libreoffice.org/68520
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
It passed "make check" on Linux.
Just to spot it to devs. It seems to me it's not
used anymore.
Change-Id: I9549e4895d2e89a61d478ff26e142a4ddbd976df
Reviewed-on: https://gerrit.libreoffice.org/68616
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
This reverts commit 9865440d21.
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>
(the negated value is ultimately passed to a short parameter of
SvxLRSpaceItem::SetTextFirstLineOfstValue. This change has no acutal effect on
the result, but silences Clang -fsanitize=implicit-signed-integer-truncation
warnings.
Change-Id: Ieefab13b9594fb6e19953c5f0ca22b36141ff986
Reviewed-on: https://gerrit.libreoffice.org/68648
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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
Move XSimpleText Java tests to C++ for ScAnnotationObj
(this also fixes i109517).
Change-Id: Ieed0c94ed7a426c921c099a1edb520cbfd830656
Reviewed-on: https://gerrit.libreoffice.org/68632
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
This adds test cases for N(data length) for non powers of 2.
This tests real and complex input cases. It also tests polar and
non-polar output case. The reference(expected) numbers were obtained
using fft() of Matlab R2018b. Finally the inverse transform is
compared is compared with original inputs for correctness.
Change-Id: Ibc13fb5ce900facd3fb0896e85a4e0d1694ad7f3
Reviewed-on: https://gerrit.libreoffice.org/68640
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
For inputs that are not an even power of 2, use
Bluestein's algorithm[1] to match the output of
fft()/ifft() in Octave/Matlab() in those cases.
This algorithm is slower than radix-2 FFT algorithm
but still has the asymptotic time complexity of
O(N lg(N)).
This patch also introduces considerable speedup in case
of real valued inputs. DFT of a real valued input of
length N can be computed using any DFT algorithm with
a N/2 length complex valued input, provided we do some
pre and post processing[2].
All implementations in this patch are written from scratch
using the below theory references.
[1] https://en.wikipedia.org/wiki/Chirp_Z-transform#Bluestein.27s_algorithm
[2] Jones, K., 2010. Fast Solutions to Real-Data Discrete Fourier Transform.
In The Regularized Fast Hartley Transform (pp. 15-25). Springer, Dordrecht.
---------------------------
Below are some perf measurements for various input cases :-
Timing numbers are only for the DFT computation part and does not include
the time for writing data to the spreadsheet model. We don't use threading
yet, so these are numbers for just one cpu-core.
Exact Powers of 2
=================
Real Input size,Time (ms)
32768,2
65536,4
262144,21
1048576,185
Complex Input size, Time(ms)
32768,2
65536,5
262144,30
1048576,400
Even non-powers of 2 : 2^k - 2
================================
Real Input size,Time (ms)
32766,8
65534,20
262142,105
1048574,1440
Complex Input size, Time(ms)
32766,15
65534,36
262142,313
1048574,3332
Odd non-powers of 2 : 2^k - 1
================================
Real Input size,Time (ms)
32767,16
65535,39
262143,313
1048575,2729
Complex Input size, Time(ms)
32767,16
65535,38
262143,309
1048575,2703
Change-Id: Iccc31455e526ee5e6d18c20812dfa53defcf869f
Reviewed-on: https://gerrit.libreoffice.org/68639
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
(added recently with d559c28e9e "expand out
IMPL_XTYPEPROVIDER_START macro"), for extra compatibility safety. (At least
MSVC exports non-inline versions of such CPPUHELPER_DLLPUBLIC inline functions
from the cppuhelper DLL.) The original getTypes (added back now with
<https://gerrit.libreoffice.org/#/c/68549/> "revert ABI change from 'expand out
IMPL_XTYPEPROVIDER_START macro'") had been a non-const member function ever
since at least b525a3115f "initial import",
presumably by accident. (Whether or not to return a reference is an orthogonal
issue. With the newly added overload being LIBO_INTERNAL_ONLY, it is presumably
fine to have it return a reference for now and see whether that causes any
issues with lifetimes of temporary OTypeCollection instances.)
Change-Id: If6abcf53b46b972204598774fed7cdd34d78440b
Reviewed-on: https://gerrit.libreoffice.org/68637
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which has no effect on the result, but silences benign Clang
-fsanitize=implicit-signed-integer-truncation warnings
Change-Id: I0953914a35f2a8c4caa6f75d4918e3b3366d07e8
Reviewed-on: https://gerrit.libreoffice.org/68628
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which has no effect on the result, but silences benign Clang
-fsanitize=implicit-signed-integer-truncation warnings
Change-Id: Ic2cf38466f12462d67ceb6268d5197e13cc6143a
Reviewed-on: https://gerrit.libreoffice.org/68627
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
The context in the mxContext member does not seem to be usable for
what we need it for here. Using what
comphelper::getProcessComponentContext() returns works better. Let's
hope it has no unintended side-effects.
This likely makes the mxContext member unused, but I did not bother
removing it yet, to keep this commit minimal.
Change-Id: Ic048683b066af7952e2e84b03ea306e7daaba259
Reviewed-on: https://gerrit.libreoffice.org/68592
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
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>
Move XNameAccess Java tests to C++ for ScDataPilotItemsObj.
Change-Id: Id8e83bb68408600f471148df7527467a371590fb
Reviewed-on: https://gerrit.libreoffice.org/68611
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
Move XIndexAccess Java tests to C++ for ScDataPilotItemsObj.
Change-Id: I66888c4515e84cf0e8f051378616c0ecbf60c0e8
Reviewed-on: https://gerrit.libreoffice.org/68610
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
Move XEnumerationAccess Java test to C++ for ScDataPilotItemsObj.
Change-Id: I6123692aee130f4c5bf326676ace2a6e7ac09405
Reviewed-on: https://gerrit.libreoffice.org/68609
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
