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

Swap the order of the default and custom callback registration, since
the order of lookup is now reversed since
<https://github.com/lsh123/xmlsec/commit/968646fb9b8428174a112fce2f08b1ec89d0ed97>.

Thanks Tomas Chvatal for reporting this.

Change-Id: I60a347454701a679db4ccd8924a723a236d5edff
Reviewed-on: https://gerrit.libreoffice.org/55404Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Tomáš Chvátal <tchvatal@suse.cz>

This reverts commit 3220ada5.  The ASan heap-
use-after-free came back, as seen (seemingly reliably, this time) during
CppunitTest_sw_ooxmlimport:

> ==4510==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000c72ea8 at pc 0x7f9e4d9b567e bp 0x7ffcb2648770 sp 0x7ffcb2648768
> READ of size 8 at 0x611000c72ea8 thread T0
>  #0 in FreetypeFont::Release() const at vcl/unx/generic/glyphs/glyphcache.cxx:311:5 (instdir/program/libvcllo.so +0x68ec67d)
>  #1 in FreetypeFontInstance::~FreetypeFontInstance() at vcl/unx/generic/glyphs/glyphcache.cxx:371:25 (instdir/program/libvcllo.so +0x68efdc7)
>  #2 in FreetypeFontInstance::~FreetypeFontInstance() at vcl/unx/generic/glyphs/glyphcache.cxx:368:1 (instdir/program/libvcllo.so +0x68efe6e)
>  #3 in LogicalFontInstance::Release() at vcl/source/font/fontinstance.cxx:136:13 (instdir/program/libvcllo.so +0x6376ceb)
>  #4 in FreetypeFont::~FreetypeFont() at vcl/unx/generic/glyphs/freetype_glyphcache.cxx:488:21 (instdir/program/libvcllo.so +0x68ab549)
>  #5 in GlyphCache::InvalidateAllGlyphs() at vcl/unx/generic/glyphs/glyphcache.cxx:57:9 (instdir/program/libvcllo.so +0x68e6c6c)
>  #6 in GlyphCache::~GlyphCache() at vcl/unx/generic/glyphs/glyphcache.cxx:47:5 (instdir/program/libvcllo.so +0x68e664c)
>  #7 in GlyphCache::~GlyphCache() at vcl/unx/generic/glyphs/glyphcache.cxx:46:1 (instdir/program/libvcllo.so +0x68e6fde)
>  #8 in std::default_delete<GlyphCache>::operator()(GlyphCache*) const at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/unique_ptr.h:81:2 (instdir/program/libvcllo.so +0x68679d9)
>  #9 in std::unique_ptr<GlyphCache, std::default_delete<GlyphCache> >::~unique_ptr() at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/unique_ptr.h:274:4 (instdir/program/libvcllo.so +0x6867739)
>  #10 in std::unique_ptr<GlyphCache, std::default_delete<GlyphCache> >::~unique_ptr() at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/unique_ptr.h:271:7 (instdir/program/libvcllo.so +0x68675ce)
>  #11 in (anonymous namespace)::GlyphCacheHolder::~GlyphCacheHolder() at vcl/headless/svpglyphcache.cxx:33:12 (instdir/program/libvcllo.so +0x686667e)
>  #12 in __run_exit_handlers at /usr/src/debug/glibc-2.27-56-g50df56ca86/stdlib/exit.c:108:8 (/lib64/libc.so.6 +0x3966b)
>  #13 in __GI_exit at /usr/src/debug/glibc-2.27-56-g50df56ca86/stdlib/exit.c:139:3 (/lib64/libc.so.6 +0x3979b)
>  #14 in __libc_start_main at /usr/src/debug/glibc-2.27-56-g50df56ca86/csu/../csu/libc-start.c:342:3 (/lib64/libc.so.6 +0x23191)
>  #15 in _start at <null> (workdir/LinkTarget/Executable/cppunittester +0x42f349)
>
> 0x611000c72ea8 is located 104 bytes inside of 216-byte region [0x611000c72e40,0x611000c72f18)
> freed by thread T0 here:
>  #0 in operator delete(void*, unsigned long) at /data/sbergman/github.com/llvm-project/llvm-project-20170507/compiler-rt/lib/asan/asan_new_delete.cc:162:3 (workdir/LinkTarget/Executable/cppunittester +0x53a060)
>  #1 in GlyphCache::InvalidateAllGlyphs() at vcl/unx/generic/glyphs/glyphcache.cxx:57:9 (instdir/program/libvcllo.so +0x68e6c7c)
>  #2 in GlyphCache::~GlyphCache() at vcl/unx/generic/glyphs/glyphcache.cxx:47:5 (instdir/program/libvcllo.so +0x68e664c)
>  #3 in GlyphCache::~GlyphCache() at vcl/unx/generic/glyphs/glyphcache.cxx:46:1 (instdir/program/libvcllo.so +0x68e6fde)
>  #4 in std::default_delete<GlyphCache>::operator()(GlyphCache*) const at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/unique_ptr.h:81:2 (instdir/program/libvcllo.so +0x68679d9)
>  #5 in std::unique_ptr<GlyphCache, std::default_delete<GlyphCache> >::~unique_ptr() at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/unique_ptr.h:274:4 (instdir/program/libvcllo.so +0x6867739)
>  #6 in std::unique_ptr<GlyphCache, std::default_delete<GlyphCache> >::~unique_ptr() at /usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/bits/unique_ptr.h:271:7 (instdir/program/libvcllo.so +0x68675ce)
>  #7 in (anonymous namespace)::GlyphCacheHolder::~GlyphCacheHolder() at vcl/headless/svpglyphcache.cxx:33:12 (instdir/program/libvcllo.so +0x686667e)
>  #8 in __run_exit_handlers at /usr/src/debug/glibc-2.27-56-g50df56ca86/stdlib/exit.c:108:8 (/lib64/libc.so.6 +0x3966b)
>
> previously allocated by thread T0 here:
>  #0 in operator new(unsigned long) at /data/sbergman/github.com/llvm-project/llvm-project-20170507/compiler-rt/lib/asan/asan_new_delete.cc:93:3 (workdir/LinkTarget/Executable/cppunittester +0x538c20)
>  #1 in FreetypeManager::CreateFont(FontSelectPattern const&) at vcl/unx/generic/glyphs/freetype_glyphcache.cxx:351:12 (instdir/program/libvcllo.so +0x68a7b34)
>  #2 in GlyphCache::CacheFont(FontSelectPattern const&) at vcl/unx/generic/glyphs/glyphcache.cxx:194:29 (instdir/program/libvcllo.so +0x68eb345)
>  #3 in CairoTextRender::setFont(FontSelectPattern const*, int) at vcl/unx/generic/gdi/cairotextrender.cxx:104:61 (instdir/program/libvcllo.so +0x686889e)
>  #4 in CairoTextRender::SetFont(FontSelectPattern const*, int) at vcl/unx/generic/gdi/cairotextrender.cxx:355:5 (instdir/program/libvcllo.so +0x686db63)
>  #5 in SvpSalGraphics::SetFont(FontSelectPattern const*, int) at vcl/headless/svptext.cxx:30:23 (instdir/program/libvcllo.so +0x6863c53)
>  #6 in OutputDevice::getFallbackFont(FontSelectPattern&, int, ImplLayoutArgs&) const at vcl/source/outdev/font.cxx:1297:17 (instdir/program/libvcllo.so +0x4ae1a8d)
>  #7 in OutputDevice::ImplGlyphFallbackLayout(std::unique_ptr<SalLayout, std::default_delete<SalLayout> >, ImplLayoutArgs&) const at vcl/source/outdev/font.cxx:1373:48 (instdir/program/libvcllo.so +0x4ae3854)
>  #8 in OutputDevice::ImplLayout(rtl::OUString const&, int, int, Point const&, long, long const*, SalLayoutFlags, vcl::TextLayoutCache const*) const at vcl/source/outdev/text.cxx:1363:22 (instdir/program/libvcllo.so +0x4b32af9)
>  #9 in OutputDevice::GetTextBreak(rtl::OUString const&, long, int, int, long, vcl::TextLayoutCache const*) const at vcl/source/outdev/text.cxx:1417:45 (instdir/program/libvcllo.so +0x4b3e4a0)

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

otherwise the database document still has the embedded storage
open when the attempt to remove the storage is made

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

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

Originally added with 78e8d5f0 "Added option to
hide external link buttons on Start Center".

The use of BackingWindow::mnHideExternalLinks was remove with
74144e53 "startcenter: Tweak Start Center
layout", and then the member and its initialization from the
StartCenterHideExternalLinks configuration property was removed with
d7824bf1 "loplugin:unusedfields in sfx2 part2".

(The opportunity to already remove STARTCENTER_HIDE_EXTERNAL_LINKS from
instsetoo_native/util/openoffice.lst.in had been missed in
89ac3c4a "replace variables in main.xcd already
in gbuild".)

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

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

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