... when the first page has a heading
Regression from commit 17e51f427b (DOCX
import: first page header should always set default headers as well,
2014-11-21), the problem is around how to split a first + follow page
style on import, and then do the opposite on export.
This is described using a single section in OOXML, but Writer has 2 page
styles for this (unlike in case of the DOC filter). This means the
header margin has to be taken from one of these page styles. The above
commit tweaked the import, so the follow page style has the wanted
header margin, but this leads to incorrect layout.
Fix the problem by tweaking the export instead: it has random access to
the doc model, so it can take the header margin from the first page
style if needed, and then the import side can be reverted, leading to
correct layout.
Also remove some leftover debug code in test/, which was added in commit
5352d45dd4 (convert AnimationImport to
fast-parser APIs, 2020-02-18).
Change-Id: I4bbf7271f3a437e8432399bd1e32e9d24190a501
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94013
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
The line shape itself didn't really have a height, rather it had a
stroke. For some reason, the SVG mask then decides that nothing has to
be painted there, so unless the line is entirely opaque, the line shape
gets lost on export.
Fix the problem by handling transparency similar to the PDF export,
which detects if the whole purpose of the transparency gradient is to
pass around a transparency percentage. We don't need a mask in that
case, we can just use opacity as described at e.g.
<https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/opacity>.
Change-Id: I0355b9b09b6dd48bbacc5b7cc54fb71866304ef1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91932
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The validator cmdline is fairly nontrivial, log it so that in case it
fails, one can invoke it manually without having to hunt down the string
in a debugger.
Change-Id: Id18c6d67f1b3b78da31e8be8c60f703623b80309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89875
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
GpgComponentFactory is unused since:
commit 06d7dbb356
Date: Sun May 21 14:28:57 2017 +0200
gpg4libre: share static xmlsec lib between nss and gpg
tableautoformatfield.cxx should have been removed in:
commit 5990beed9a
Date: Fri Aug 29 16:37:43 2014 +0200
Dead code
xmlRow is unused since initial import
Change-Id: Ief186e9ef46238cc8cdb49f4adde52a45a98cbc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89830
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
And...
(*) space out the namespace constant values so I dont
keep forgetting and making them overlap.
(*) Remove CreateDocumentContext from SvXMLImport since it is
now unused.
Change-Id: I30f54bfc1389e91b18e4fee8b83e1b297419899b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88938
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Change-Id: I0895478ec5bbb69cc8a7d88d848755aeabe7b51d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88350
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)
o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like
static_cast<sal_uInt32>(n) >= c
used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative. It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives. The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".
But which of course does not mean that there were no further false positivies
that I missed. So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned. At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.
It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious. But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now. (The
ultimate fix being to get rid of the macro in the first place.)
Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Change-Id: Ic525a57880067fc589346b87237c08fae4644ac5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87403
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Id1ee9b6d44315443d023bdfbf9ae8e5aa2158ab2
Reviewed-on: https://gerrit.libreoffice.org/85171
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
in CPPUNIT_ASSERT... the first parameter is the expected value and
the second the actual value. Passing them swapped is confusing if
the test is failing.
Change-Id: I06f8f345d52c3743d10441aae6d8c943f9b49b41
Reviewed-on: https://gerrit.libreoffice.org/84635
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Tests are executed in sequence, inserting a sheet with each
importSheetToCopy(), ended up with 'SheetToCopy_4' as the first
sheet (last sheet inserted), but obtained "destination" values
from sheet 'SheetToCopy' (the first sheet inserted) whatever may
have happened to its references during the previous tests or by
inserting more sheets in front of it.
Instead of obtaining the destination sheet by name 'SheetToCopy',
obtain it by index 0 where it was inserted
We could also remove the inserted sheet after each test, but
likely a cleaner approach would be to setup a fresh document to be
inserted into for each test to avoid any side effects like names
already being present from a previous insertion.
Change-Id: I38f35ccac7d656026b6fec8d3c5faa68d6f4a642
Reviewed-on: https://gerrit.libreoffice.org/84631
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
...where success of >>= has already been checked with CPPUNIT_ASSERT
Change-Id: I9aa553749988b6b2e26d9a5ac5b376cc5997aba7
Reviewed-on: https://gerrit.libreoffice.org/84335
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It started out as a wrapper around character literals, but has by now become a
wrapper around arbitrary single characters. Besides updating the documentation,
this change is a mechanical
for i in $(git grep -Fl OUStringLiteral1); do sed -i -e s/OUStringLiteral1/OUStringChar/g "$i"; done
Change-Id: I1b9eaa4b3fbc9025ce4a4bffea3db1c16188b76f
Reviewed-on: https://gerrit.libreoffice.org/80892
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for OUStringBuffer append sequences that can be turned
into creating an OUString with + operations
Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6
Reviewed-on: https://gerrit.libreoffice.org/80809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which defeat the *StringConcat optimisation.
Also make StringConcat conversions treat a nullptr as an empty string,
to match the O*String(char*) constructors.
Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b
Reviewed-on: https://gerrit.libreoffice.org/80724
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
mostly so that my stringadd loplugin can point out places to improve
Change-Id: I9920ee1c99cdb6b811ba67ff9d8e32aa261884b5
Reviewed-on: https://gerrit.libreoffice.org/80618
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so...
SAL_USE_VCLPLUGIN=gtk3 make screenshot
for the "unknown dialog" cases of make screenshot, which loads .ui files and
tries to render them, will render them with the native gtk infrastructure
Change-Id: Ifc8fe264155887c4d01b7ce0e2aa53e12acbfcb0
Reviewed-on: https://gerrit.libreoffice.org/80545
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
New IWYU and recent developments in f-u-i helped to identify
some non self contained files, those were fixed too.
Change-Id: I527f7c2cf2660a758b13eabb4c444ff79ae35f8c
Reviewed-on: https://gerrit.libreoffice.org/75186
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
ODF validator may now actually exit with non-0 since commit
b14e2f6c63c18894286c99ee8dde9070e24b41c2 - look for validation errors in
this case too.
Change-Id: I36f4437c54d9a60afee0663a0b9be206773c5378
Reviewed-on: https://gerrit.libreoffice.org/75964
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
