This adds FileDefinitionWidgetDraw which extends the
WidgetDrawInterface and is responsible to draw the widgets from
the definition gathered from an external file. The file must be
(currently) in the user folder named definition.xml.
It instantiates the WidgetDefinitionReader to get the definitions
and sets the style colors when updateSettings is called. Later
more definitions will be implemented.
Change-Id: Id02111e8aed4648e5a306b0f5dbc9a02c9b2fcb0
Reviewed-on: https://gerrit.libreoffice.org/68645
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
WidgetDefinitionReader is responsible to read the definitions from
an xml file. The first implemented definitions are style colors.
They are read from the file and stored into class fields.
This also adds the unit test which tests that the reader is
functioning as expected for a small certain subset of colors.
Change-Id: Icd44cb465b084c32db8323e2f2f7dfa57823d559
Reviewed-on: https://gerrit.libreoffice.org/68642
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Similar fix to b38065ea94
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>
At least during CppunitTest_sw_odfimport, Clang's
-fsanitize=implicit-signed-integer-truncation warns (for nB) that an "implicit
conversion from type 'long' of value -181 (64-bit, signed) to type 'const
sal_uInt16' (aka 'const unsigned short') changed the value to 65355 (16-bit,
unsigned)".
Change-Id: I91bd1413fca248f5f05331980d8ac92753d366ab
Reviewed-on: https://gerrit.libreoffice.org/68665
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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>
