Update of blacklist for $WITH_THEMES
Fallback to Tango for ancient/unknown DE, Colibre only on Windows
MPL vs. non-MPL on macOS

Change-Id: Ibea9e9429a79911d632b54fa4aa9649003830aa3
Reviewed-on: https://gerrit.libreoffice.org/55295Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/54794

Change-Id: Ic7e1cecaecadf3f9ebfa183727d61046dd87e473
Reviewed-on: https://gerrit.libreoffice.org/55260Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>

Revert "dont use GetMask in GeoTexSvxBitmapEx"

This reverts commit 63e65d17.

Until we come up with something better

Change-Id: I246468abdd5e3ee917143e251c2e95430d84f77b
Reviewed-on: https://gerrit.libreoffice.org/55385Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I961686c1257f0d85686df06aa7c73c324d0f70b8
Reviewed-on: https://gerrit.libreoffice.org/55387Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

An object returned by XCollection::Item() is of the right "VBA" kind
that we want. One returned by XEnumeration::nextElement() is not.

Change-Id: I26132a7d0f2638a61f2711b941386a889fabea72
Reviewed-on: https://gerrit.libreoffice.org/55392Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>

There is a bug in the conversion from
while(rRect.Bottom() > aNewPos.Y() + aVisAreaSize.Height())
to
const long distBottom(rRect.Bottom() - aNewPos.Y() + aVisAreaSize.Height());

While the bottom of the object is lower on the page than
the visual Top position plus the height of the screen,
(in other words, it isn't in the visible range of the screen),
move the screen down by the size of the object and try again.

The loop could first be finished when the shape bottom is
exactly at the bottom of the screen:
rRect.Bottom() = aNewPos.Y() + screen Height.
or rRect.Bottom() - (aNewPos.Y() + aVisAreaSize.Height()) = 0
or rRect.Bottom() -  aNewPos.Y() - aVisAreaSize.Height()  = 0

Change-Id: I762a39df3cdcd5689c8f6742797a9f7b38ddb384
Reviewed-on: https://gerrit.libreoffice.org/55156Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>

Change-Id: Ieed538741f2a252c8acf1e751bb2ddbe6361b2fa
Reviewed-on: https://gerrit.libreoffice.org/55118Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Szymon Kłos <szymon.klos@collabora.com>

Opcode ocExternal is used for functions implemented as UNO calls,
which has a number of problems:
- ooo#118213-2 contains GETEOMONTH(), which maps to ocExternal, which
  calls AnalysisAddIn::getEomonth() in scaddins, which ends up calling
  ScModelObj::getPropertyValue(), which deadlocks on SolarMutex
- it uses ScUnoAddInCollection class, which uses delayed initialization
  (even though it's created on-demand), which is not thread-safe; however,
  it seems that the initialization is generally done already while loading
  a file, so this is possibly in practice safe
- who knows what all kinds of race conditions there are in all the functions
  this may call via UNO

Change-Id: I80c4264102b8bc492853852c2c12e5cd2a8ea99e
Reviewed-on: https://gerrit.libreoffice.org/55382Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>

This is surely an utter abuse of focus and an a11y disaster, but it
used to work this way.

Change-Id: I265a2bafbc2cdd17ff4a5b7c2805def63c510d5c
Reviewed-on: https://gerrit.libreoffice.org/55373Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Project: help  4b66c47d5c27ba8136735b95e4d595d499cb9ec2

Clean up space/tab mixture

At least Emacs warned about those "suspicious lines".

Change-Id: I587e7d65318a7fdb1634e49f2db761c853e67b05
Reviewed-on: https://gerrit.libreoffice.org/55383Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Project: help  5197a6b9def2e1886e3edab75517864272115089

(Partially) fix --with-help=html dependencies on .xhp files

There are three rules in helpcontent2/CustomTarget_html.mk that process (with
XSLT) all or some of the .xhp files in the helpcontent2/source/text/ tree (for
en-US; or their translations in the
workdir/HelpTranslatePartTarget/*/helpcontent2/source/text/ trees for other
languages).  Lists of all those .xhp files are defined in
helpcontent2/AllLangHelp_*.mk (with gb_AllLangHelp_add_helpfiles), but the code
in helpcontent2/CustomTarget_html.mk used `find` to assemble the relevant lists.

That has two issues (at least for the en-US case operating on the untranslated
helpcontent2/source/text/ files):  For one, if the content of those .xhp files
changes, the relevant XSLT processing is not re-run.  For another, if .xhp files
are added to or removed from the lists in helpcontent2/AllLangHelp_*.mk, the
relevant XSLT processeing is not re-run, either.

For the processing of translated .xhp files, there were already dependencies on
those translated files in place.  I assume (but have not really proved it) that
those dependencies are already sufficient to cover both of the above issues.
That only leaves the en-US case, operating on the untranslated files.

The lists of .xhp files as defined in helpcontent2/AllLangHelp_*.mk (with "*"
ranging over the various "modules": sbasic, scalc, schart, etc.) are now made
available in gb_AllLangHelp_*_HELPFILES variables.  The contents of those
variables is used instead of `find` to pass the relevant .xhp files to the XSLT
processings.  (Needing some RESPONSEFILE and `xargs -n 1` boilerplate to feed
individual files to the XSL processing without overflowing maximum command line
lengths.  Also, on Windows, var2file apparently writes CRLF line ends but the CR
parts need to be filtered out again, and xargs problems must be worked around
similar to df9edbcd "Work around 'xargs:
environment is too large for exec' errors on Windows".)

However, those variables apparently cannot be used to specify dependencies for
the three XSLT-processing rules.  Presumably, the variables do not necessarily
have their values assigned yet by the time the rules' dependencies are
constructed (depending on the order in which .mk files are read?).  So "dummy"
gb_AllLangHelp_get_helpfiles_target targets are introduced, which depend on all
the relevant .xhp files (and which get constructed during
gb_AllLangHelp_add_helpfiles, just like the gb_AllLangHelp_*_HELPFILES
variables), and which the XSLT-processing rules in turn depend on.  That makes
sure that the XSLT-processing rules are re-run when the content of .xhp files
changes or when new .xhp files are added.

However, the above still fails to re-run the XSLT-processing rules when .xhp
files are removed.

This is the helpcontent2 part of a commit spanning core and helpcontent2.

Change-Id: I9a72c0f6837a8e13458a703fdecf7e5b0ef2076f
Reviewed-on: https://gerrit.libreoffice.org/55364Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

There are three rules in helpcontent2/CustomTarget_html.mk that process (with
XSLT) all or some of the .xhp files in the helpcontent2/source/text/ tree (for
en-US; or their translations in the
workdir/HelpTranslatePartTarget/*/helpcontent2/source/text/ trees for other
languages).  Lists of all those .xhp files are defined in
helpcontent2/AllLangHelp_*.mk (with gb_AllLangHelp_add_helpfiles), but the code
in helpcontent2/CustomTarget_html.mk used `find` to assemble the relevant lists.

That has two issues (at least for the en-US case operating on the untranslated
helpcontent2/source/text/ files):  For one, if the content of those .xhp files
changes, the relevant XSLT processing is not re-run.  For another, if .xhp files
are added to or removed from the lists in helpcontent2/AllLangHelp_*.mk, the
relevant XSLT processeing is not re-run, either.

For the processing of translated .xhp files, there were already dependencies on
those translated files in place.  I assume (but have not really proved it) that
those dependencies are already sufficient to cover both of the above issues.
That only leaves the en-US case, operating on the untranslated files.

The lists of .xhp files as defined in helpcontent2/AllLangHelp_*.mk (with "*"
ranging over the various "modules": sbasic, scalc, schart, etc.) are now made
available in gb_AllLangHelp_*_HELPFILES variables.  The contents of those
variables is used instead of `find` to pass the relevant .xhp files to the XSLT
processings.  (Needing some RESPONSEFILE and `xargs -n 1` boilerplate to feed
individual files to the XSL processing without overflowing maximum command line
lengths.  Also, on Windows, var2file apparently writes CRLF line ends but the CR
parts need to be filtered out again, and xargs problems must be worked around
similar to df9edbcd "Work around 'xargs:
environment is too large for exec' errors on Windows".)

However, those variables apparently cannot be used to specify dependencies for
the three XSLT-processing rules.  Presumably, the variables do not necessarily
have their values assigned yet by the time the rules' dependencies are
constructed (depending on the order in which .mk files are read?).  So "dummy"
gb_AllLangHelp_get_helpfiles_target targets are introduced, which depend on all
the relevant .xhp files (and which get constructed during
gb_AllLangHelp_add_helpfiles, just like the gb_AllLangHelp_*_HELPFILES
variables), and which the XSLT-processing rules in turn depend on.  That makes
sure that the XSLT-processing rules are re-run when the content of .xhp files
changes or when new .xhp files are added.

However, the above still fails to re-run the XSLT-processing rules when .xhp
files are removed.

This is the core part of a commit spanning core and helpcontent2.

Change-Id: I0cb5f83097db17fbd7ae8b528418b0ec24bee602
Reviewed-on: https://gerrit.libreoffice.org/55363Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

And correct a few comments (translation and grammar)

Change-Id: Ifafa521c683e9ca65aeba8031cd4cbfc1fadc137
Reviewed-on: https://gerrit.libreoffice.org/54888Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>

...using o3tl::ThreadSafeRefCountingPolicy due to being
used indirectly (~Bitmap) in parallelized 3D renderer

Change-Id: Ia5eab219c6844570a04c83f71cca5e7b7da4326d
Reviewed-on: https://gerrit.libreoffice.org/55365Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>

Change-Id: Ibdcad8101fbd4a0344fb82d3e5d03774d1b125dc
Reviewed-on: https://gerrit.libreoffice.org/54980Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Before commit b366adcf this function didn't do anything for unhandled
opcodes, but the commit made the else branch disable vectorization
for "the rest" of opcodes. That meant that basic opcodes such as ocAdd,
which didn't get thrown out by the SC_OPCODE_START_BIN_OP block (since they
are in the allowed subset), ended up in the else block and vectorization
got disabled.

Change-Id: I9eb408b601f48b8d7b5022ec85225d92729cd778
Reviewed-on: https://gerrit.libreoffice.org/55362Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Jump opcodes such as ocIf are quite clearly not in the function range,
as can be seen in include/formula/opcode.hxx . This used to be harmless,
since originally ScTokenArray::CheckToken() didn't do anything in the default
case, but commit b366adcf changed it to disable vectorization for
unhandled opcodes.

Change-Id: Ia182f446f1da819e18309075aa00251674640c74
Reviewed-on: https://gerrit.libreoffice.org/55361Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: If7ce44786975c5f9bdc9e64d16274728b03bed32
Reviewed-on: https://gerrit.libreoffice.org/55355Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

to see if this is still a problem after 'fix dubious cache comparison check'

This reverts commit b0be0d41.

Change-Id: I253a67c3aa5f8daf0e8cd586a5089e554e48f355
Reviewed-on: https://gerrit.libreoffice.org/55185Tested-by: Jenkins <ci@libreoffice.org>
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.
Quite a bit of fallout management was necessary.
Several files were not checked earlier because of IWYU problems.
Also a few mistaken entries from the yaml file are corrected.

Change-Id: I943dfb955e096896961ac487d26ce57a6cb76cc2
Reviewed-on: https://gerrit.libreoffice.org/55303Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

When calculating the height of the top/bottom margin, we take into
account whether the DOC section has a header/footer enabled.

If the DOC section contains only a first-page header/footer, and the
display of first-page header/footer in this section is not enabled,
then we must consider the section to have no header/footer.

(Also add a test case using the doc supplied by the reporter in
 tdf#117885)

Change-Id: I8040298a2953b3f3fe8dd80bfd62db2304db938e
Reviewed-on: https://gerrit.libreoffice.org/55135Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>

requires a handful of workarounds

Change-Id: I77c25580135eeec437716eceea1412607f8d14ca
Reviewed-on: https://gerrit.libreoffice.org/55244Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>

It's pointless, include guards will make sure it's a NOP, but it
confuses tools like IWYU.

Change-Id: Ic1f56ef267954cdf8bf3cb4f4a5e841d5e4bb82a
Reviewed-on: https://gerrit.libreoffice.org/55354Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Project: help  3765355e41d02ee3e5f64ef6ece336641553e7c7

Cleanups and improvements

Help files in scalc/00/

Change-Id: I55ffb4961fb5614f75fbc3e71dd50b461dff17de
Reviewed-on: https://gerrit.libreoffice.org/54603Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Id17b0d8e26658bc3b140bd26a37a990e51e08409
Reviewed-on: https://gerrit.libreoffice.org/55356Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: andreas_kainz <kainz.a@gmail.com>

Change-Id: Ie15bf9b3d5e8b1aa5dc4f13a591b7ef84b4c9abe
Reviewed-on: https://gerrit.libreoffice.org/55342Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>

Change-Id: I0d8fb6c6adc44389332434f9f6a8396a4d1817cf
Reviewed-on: https://gerrit.libreoffice.org/55337Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

selecting the index sets it as active and updates the previews, so if its an
inactive index and resize happens, leave it as inactive but selected

Change-Id: If823f6b3e8f2ee4e77ba5e5d0202d72893ed614c
Reviewed-on: https://gerrit.libreoffice.org/55344Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

... and rename temporary rCurrentRange to aCurrentRange.

Change-Id: I423d3c4ea018ec210cf4a59eb284cc6c5f2e8986

Previously if an entire column was selected, the top data row was
taken and then that X,Y position used to extend to the data area.
Else the current view's X,Y was used to extend to the data area.

Now keep a selection and use current X,Y only if there is no area
selected.

Change-Id: I19ce52bc2ebf4813b779600a4738ed1f82643aa7
Reviewed-on: https://gerrit.libreoffice.org/55348Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I32882ef35c84e753b2e008d7f46915d73f3fe5df
Reviewed-on: https://gerrit.libreoffice.org/55240Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

The export filter writes /DeviceRGB unconditionally, so for now don't
optimize CMYK image handling here. Though the added GraphicDescriptor
API allows supporting this natively in the export filter in the future.

Change-Id: I76b44b910948467aeb1f15e5ae765201d183c99d
Reviewed-on: https://gerrit.libreoffice.org/55343Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

Change-Id: I31c84eb2267b4978f110a4f38cbf4d2377d59400

as MustHaveParamCount() already does it when returning false.

Change-Id: Ia4f8998a2f65eea5e6be3fd21b5ca724d13770d0
Reviewed-on: https://gerrit.libreoffice.org/55265Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: If8c88994f68a8a644d1ce4e2386d3247140e824f
Reviewed-on: https://gerrit.libreoffice.org/55322Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Still some holdouts from that bad old habit it seems.

Change-Id: Ib0fe2c7eb006649b121668c549ff8e0bb060e120
Reviewed-on: https://gerrit.libreoffice.org/55331Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I78999730bc942733d7498415d920d94f2422ac6f
Reviewed-on: https://gerrit.libreoffice.org/55329Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Illustration Index has been renamed to Table of Figures
Default category changed from Illustration to Figures

Change-Id: I2c4fbf4036c245ea98cda4e3652c300449abd4b1
Reviewed-on: https://gerrit.libreoffice.org/54372Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Heiko Tietze <tietze.heiko@gmail.com>
Reviewed-by: Heiko Tietze <tietze.heiko@gmail.com>

Change-Id: I7c5f2dadcbbe543a774f5fbdd52babd25b8b17d1
Reviewed-on: https://gerrit.libreoffice.org/55319Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: I0887a1caea96f3efe897c304cde0520d59da6c59
Reviewed-on: https://gerrit.libreoffice.org/55323Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>