a problem since...
commit 69c546e1e7
Author: Caolán McNamara <caolanm@redhat.com>
Date: Fri Dec 4 16:30:31 2020 +0000
weld annotation window
this sidebar case assumes that the papersize of the underlying
editengine is initially unlimited in size
Change-Id: I127f249158deecef3e2c6874982b4e7cc78e69fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124656
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
For instance, the driver for my printer (or maybe Windows itself, no
idea where the list of sizes comes from originally) says it supports
215 x 345 mm. Which apparently is an obscure paper size called "India
Legal". It is confusing if the Print dialog claims that it is "User
Defined" when I have never even heard of such a size, and the document
does not specify it either.
Change-Id: I44196fd21fd83a94d255ebb909e5d63e35c5d1e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124649
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
when setting a new size because an absolute size set by gtk itself seems
to be not overwritten by pango_attr_size_new so sometimes the size of
the font in the annotation window label is too large
Change-Id: Ib69eec2111336cc27d1571babcc891f16cae2f01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124641
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
...similarly to how it was already done for its
ucb/source/ucp/webdav-neon/NeonSession.cxx cousin
Change-Id: I78124f45d4cb08131ee5d6e8c2606b38407c0668
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124637
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The help message for that option even said "With current Xcode
versions, only the latest SDK is included, so this option is not
terribly useful". And that was written in 2016. So by now, the
--with-macosx-sdk option surely has outlived its usefulness.
Change-Id: I467194c96c571822c08ea82bb7e62f0e2a2d332b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124549
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
I could not reproduce it now but at least in some slightly older
version of LibreOffice, it could happen that at the top of the print
preview image was displayed "143 mm (A4)" which is silly, as neither
side of an A4 paper is 143 mm.
Look up the matching paper size from the dimensions displayed. Use the
"sloppy" match function to allow for sub-millimeter rounding errors.
Change-Id: I6320798061246101c6fc78baf841b71b32b25833
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124612
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
1 CppuniTest makefile should be sufficient, particularly since all 4
of them used gb_CppunitTest_use_library_objects so this should reduce
wasted space.
Change-Id: I485f0af0aee2b265b56c505ced44257834784e98
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124608
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
There's no point in building the tests for neon any more, just build
them only if curl is used.
This finds a bug in CurlUri::Init() where query and fragment separators
need to be added manually.
Change-Id: I3dcd1512450522df2c2a7d223b2e29b6c0e794fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124607
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
See commit a226cec52e
(CppunitTest_sw_rtfimport: convert one testcase to use
CPPUNIT_TEST_FIXTURE(), 2019-11-05) for motivation.
Change-Id: I08a4ba4a1219b90a3652ae63c1e3a11dd9fa1208
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124614
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
> Testing load file:///~/lo/core//sw/qa/core/data/html/pass/ofz40593-1.html:
> sw/source/filter/html/svxcss1.cxx:2869:44: runtime error: 1.70141e+38 is outside the range of representable values of type 'long'
during CppunitTest_sw_filters_test with test file newly added with
2f01faaf88 "ofz#40593 remove Objects from
m_xResizeDrawObjects if deleted during parse"
Change-Id: Ida97b886c254272fd2a506a8d7ad2319fed72dcc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124623
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These test documentations are completely pointless.
They test something implementation specific without
anything to actually test for accuracy.
4-test_segfault_while_save.docx: pseudo-preventative test.
8-fdo49940.docx: an empty page with no header/footer enabled.
Who cares if it is called Default style or First Page.
Change-Id: I4a9a6fcfe3621eaa745470487b32b2cbd66f0973
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124590
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
...in templated code, to cater for the needs of
<https://gerrit.libreoffice.org/c/core/+/124400> "Prepare for removal of
non-const operator[] from Sequence in testtools".
For one, by defining ImplicitBoolConversion::TraverseInitListExpr, make sure
that Clang versions before and after
<0a42fe70a5>
"[AST] Treat semantic form of InitListExpr as implicit code in traversals"
behave the same. Old versions of Clang would have erroneously reported
Sequence<Sequence<sal_Bool>> s2{ { false } };
(and reported
Sequence<Sequence<sal_Int32>> s4{ { false } };
twice) in compilerplugins/clang/test/implicitboolconversion.cxx when one of the
four combinations of syntactic/semantic visit of the outer/inner InitListExpr
defeated the intended suppression logic in
ImplicitBoolConversion::TraverseCXXStdInitializerListExpr.
And for another, ImplicitBoolConversion::TraverseInitListExpr can subsume the
exising ImplicitBoolConversion::TraverseCXXStdInitializerListExpr.
But for a third, that would still make
Sequence<Wrap2<sal_Bool>> s6{ { false } };
in compilerplugins/clang/test/implicitboolconversion.cxx emit a false warning,
so add a cheesy "TODO" chicken-out special case to
ImplicitBoolConversion::checkCXXConstructExpr for now.
Change-Id: Ib9a1b78a7812feb98c673b75a357af7737168342
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124583
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Previously we stored a pointer to the gutter margin XMLPropertyState
so we could read it later. The problem with this is that in between
when we storing and reading the property state, we add elements
to the rProperties vector, where the XML properties are allocated.
Adding new elements to the vector can cause that the internal
array is reallocated to a bigger size and elements copied to the
new array, so our pointer shows to a invalid (deallocated) memory
address.
This issue is fixed by moving the code up to before we add new
elements to rProperties vector and a big warning is written to not
use XMLPropertyState* pointers after the code adds to the
rProperties vector.
Change-Id: I24b0285d49e678fcb3b333bf4054f5cef4207003
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124572
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
outline content type member count
Outline content type member count can be less than the number of
outline nodes in the document model if the outline level setting is
less than outline level maximum, MAXLEVEL. Currently, the outline node
count is incorrectly compared to the outline level maximum in
determining the outline content type member count. The member count is
compared against the old member count to determine if the member array
needs to be cleared and filled when a member in the array is wanted by
a call to the GetMember function. This patch changes the outline level
maximum to be compared to the set outline level.
Change-Id: Ie1348575becbbc14446b417bcd568f158330cf9a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124537
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
At least I think they must. Also add a comment to the enum pointing at
those arrays. There are now four different places in four files that
must be manually kept in sync. Quite possibly more. This stinks.
Change-Id: I7b5c721329c69a16b8cdf07390d481ec77c7b5ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124610
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
use (abuse?) a SynchronMode of true, which will become
SfxRequest::IsSynchronCall of true in SfxObjectShell::ExecFile_Impl to
request that we do not want the properties dialog to be run async. It
looks impractical to rearrange all the post-dialog-call close code to be
part of some callback executed when the dialog completes.
Change-Id: Id2bde24986204dea3d312c0b4a91bf5c0a6f7916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124606
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
