This is the first try of a new TabBar look - borders have been
removed, selected tab doesn't change the font to bold, adjustment
to the selected tab line.

Width and height of a tab item has been adjusted to make it
better to fit the icons in and to not be so cramped.

Draw "protected" status of an tab icon (in Calc) as an icon and
not as a unicode glyph.

Change-Id: If2ee930a573343166fbe9efcd94ae5159a620f22
Reviewed-on: https://gerrit.libreoffice.org/71238
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>

Seems like this is a somewhat pathological document, has lots of
duplicated ranges. Checking for duplicates makes it load in <10s on my
machine

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

Change-Id: I6607ef2c9ca0860643cd57f9bde171ea1a7ca3af
Reviewed-on: https://gerrit.libreoffice.org/71269
Tested-by: Jenkins
Reviewed-by: Rizal Muttaqin <riz_17_oke@yahoo.co.id>

When 'QFileDialog::Directory' is set, the native
Plasma QFileDialog does not consider the clicked
directory to be selected, but rather the base directory
shown in the dialog, s.
https://bugs.kde.org/show_bug.cgi?id=406464 .

Therefore don't set the option when in a KDE Plasma desktop
environment (which the kde5 VCL plugin also doesn't do).

This works around the above issue in the Plasma desktop
integration.

Change-Id: Ib3d0978ab56b6e50ee45f7ad997ec051b35faf54
Reviewed-on: https://gerrit.libreoffice.org/71223
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>

Change-Id: I7db23f84a3de4772b38c9538704f501a9169ce09
Reviewed-on: https://gerrit.libreoffice.org/71267Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>

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

...but only with old MSWord compat flag SplitPgBreakAndParaMark.

All of the other cases (COLUMN_BREAK and non-empty runs) split
the paragraph, so why not here?  This document shows it is needed,
but only for SplitPgBreakAndParaMark documents.

Note: Word 2003 doesn't display "modern" docx well in this regard.
It adds extra paragraphs where it shouldn't. There are already
example unit tests that ensure that extra paragraphs aren't written
for SplitPgBreakAndParaMark == false.

The actual bug's document is not related to the compatibility flag.
That will be handled in separate commit.

Change-Id: I27399780c909663f9a2b21974a5b385bea67f9ec
Reviewed-on: https://gerrit.libreoffice.org/70835
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>

Move TableColumn Java tests to C++ for ScTableColumnObj.

Change-Id: I3f17fa1f25c2676124b56c384364e36736fac849
Reviewed-on: https://gerrit.libreoffice.org/71261
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

Change-Id: I08d5b060b6756a89972eeec57c1f9c85e6f65500
Reviewed-on: https://gerrit.libreoffice.org/71262
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>

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

Commit a51b7a1c (tdf#103831, tdf#100986:
Force using GDI when needed, 2017-03-03) noted that the DirectWrite text
renderer doesn't support stretched text, add support for this now by
setting a DirectWrite transform matrix that only does horizontal
scaling.

With this, tdf#113076 is kept fixed, but at the same time manually
stretched text keeps working. Previously the glyphs of the text had the
correct size and position, but the glyphs themselves where not streched,
but simply aligned to the left.

Change-Id: I8fe8e74d3edc0d71ed2f16fcce66c6f5009ed264
Reviewed-on: https://gerrit.libreoffice.org/71245Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

For one, it is deprecated since Java 9, and for another it causes a
NullPointerException when called from the JNI Invocation API (i.e., without a
Java caller frame) at least with some Java 12.

(Found when doing a test build with Java 12 and JAVA_SOURCE/TARGET_VER
explicitly configured as 7 with d365f363 "Allow
to pass JAVA_SOURCE/TARGET_VER into configure".)

I have entered information about the NullPointerException at
<https://bugreport.java.com/bugreport/start_form.do>, but haven't heard back
yet, so duplicate that information here:

Issue Type:
> Bug

Component:
> Core Libraries

Operating System:
> Linux 64-bit

Java Release:
> 12

Synopsis:
> Calling java.lang.Class.newInstance from JNI Invocation API causes NullPointerEx

Description:
> I can reproduce this with the OpenJDK 12 RPMs on Fedora 30, but from looking at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/java/lang/Class.java> it looks plausible that it is a common issue that Reflection.getCallerClass() returns null when java.lang.Class.newInstance is called from the JNI Invocation API, and that null is propagated to jdk.internal.reflect.Reflection.verifyMemberAccess as parameter currentClass, which dereferences it at <https://hg.openjdk.java.net/jdk/jdk12/file/06222165c35f/src/java.base/share/classes/jdk/internal/reflect/Reflection.java#l130>.
> This is known to have been working with older OpenJDK (at least 1.8).

Steps to Reproduce:
> Compile the provided test.cc with `g++ -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include -I/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/include/linux /usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server/libjvm.so test.cc` and run it with `LD_LIBRARY_PATH=/usr/lib/jvm/java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64/lib/server ./a.out`.

Expected Result:
> exit 0

Actual Result:
> Exception in thread "main" java.lang.NullPointerException
> 	at java.base/jdk.internal.reflect.Reflection.verifyMemberAccess(Reflection.java:130)
> 	at java.base/java.lang.reflect.AccessibleObject.slowVerifyAccess(AccessibleObject.java:673)
> 	at java.base/java.lang.reflect.AccessibleObject.verifyAccess(AccessibleObject.java:666)
> 	at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:638)
> 	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:490)
> 	at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:166)
> 	at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:404)
> 	at java.base/java.lang.Class.newInstance(Class.java:590)
> Aborted

Source code for an executable test case:
> #include <cstdlib>
>
> #include "jni.h"
>
> void handleError(JNIEnv * env) {
>     if (env->ExceptionCheck()) {
>         env->ExceptionDescribe();
>         std::abort();
>     }
> }
>
> int main() {
>     JavaVM * vm;
>     JNIEnv * env;
>     JavaVMInitArgs args{JNI_VERSION_1_2, 0, nullptr, true};
>     if (JNI_CreateJavaVM(&vm, reinterpret_cast<void **>(&env), &args) != JNI_OK) {
>         std::abort();
>     }
>     auto const c1 = env->FindClass("java/lang/Class");
>     handleError(env);
>     auto const id = env->GetMethodID(c1, "newInstance", "()Ljava/lang/Object;");
>     handleError(env);
>     auto const c2 = env->FindClass("java/lang/Object");
>     handleError(env);
>     env->CallObjectMethod(c2, id);
>     handleError(env);
> }

Workaround:
> Call via JNI the suggested replacement of clazz.getDeclaredConstructor().newInstance() instead of the deprecated java.lang.Class.newInstance().

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

... which was obviously omitted in commit
6b678c13, which introduced the correct
value of 0x0491 (1169) in addition to the pre-existing 0x043C (1084).
The new value is used when user sets relevant entry in Region and
Language control panel applet (intl.cpl); having the old value in MSI
summary information blocks auto-detection of proper installer language.

[MS-LCID] Appendix A mentions that the new code is available since Win7,
so we are good with the fix.

[MS-LCID] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/a9eac961-e77d-41a6-90a5-ce1a8b0cdb9cCo-authored-by: Eike Rathke <erack@redhat.com>

Change-Id: Ic03b0e8eaf145c662fde48846cd5307e362d4d63
Reviewed-on: https://gerrit.libreoffice.org/71242Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

Had found

> sh: -c: line 0: syntax error near unexpected token `('
> sh: -c: line 0: `file /Users/stephan/Software/lo/core/instdir/LibreOffice.app/Contents/Frameworks/LibreOfficePython.framework/Versions/3.5/lib/python3.5/site-packages/setuptools/script (dev).tmpl'

in workdir/CustomTarget/instsetoo_native/install/install.phony.log on macOS.

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

re-arrange the conditions so we avoid the dynamic_cast most of the time.

This takes the file-open time from 40s to 29s for me.

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

Inherit from tools::WeakBase non-virtually, so that we can use a
static_cast in tools::WeakReference::get instead of a dynamic_cast.

This takes the file-open time from 1m21 to 40s for me.

Add a clang plugin to make sure we don't accidentally end up inheriting
from tools::WeakBase more than once.

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

(I know Swedish, this is not guesswork, there are no orthography
differences.)

Change-Id: I6f652f01dc95aa3a89fec1964c2a49109eb5e30b

On macOS, the system says it has a generic "de" dictionary. But on
iOS, it says it is specificaly "de_DE". Assume it is good enough for
the other German variants, too, for now.

Change-Id: I745cc02c1ffa774dbcbfdc1d775ce358957f04f8

spec says "An unsigned integer that MUST be 0xFFFFFFFF" for version
so at least insist on that

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

Change-Id: If846bb08ec6eceb307228bc628a4b186a3058051
Reviewed-on: https://gerrit.libreoffice.org/71230Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

Now with "Unipoll" this actually caused the app to hang. Unclear
whether this ifdef had ever been strictly needed. (But before
"Unipoll" it did not cause any harm.)

Change-Id: I5cc399f76fcdb267eb96bf7790474c14f2ce9955

Change-Id: If5781ae101e58c26368e57787cb301f84ffa82a5

in its javac invocations, so we apparently need to set those variables instead
of ant.build.javac.source/target (which are documented at
<https://ant.apache.org/manual/javacprops.html> to be supported since Ant 1.7,
but are apparently not used here).  (Found when doing a test build with Java 12
and JAVA_SOURCE/TARGET_VER explicitly configured as 7 with
<https://gerrit.libreoffice.org/#/c/71218/> "Allow to pass
JAVA_SOURCE/TARGET_VER into configure", which caused building
external/languagetool to nevertheless complain about unsupported 1.6
source/target switches.)

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

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I07d78df2d5aacbdaff7344a09812db91de17d535
Reviewed-on: https://gerrit.libreoffice.org/71113
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

...for those who pretend they know what they are doing (e.g., to experiment with
building against Java 12 which no longer supports Java 1.6 source/target, even
though that results in a build that is not baseline compatible).

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

use template to make return type match input type, so we don't need to
cast at the call sites

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

regression from
    commit 7282014e
    Date:   Fri Feb 1 15:15:16 2019 +0100
    tdf#50916 Makes numbers of columns dynamic.

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

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

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

Change-Id: I11c2ac4855a5fec2d26255ec3ab14ffe50e0fbbe
Reviewed-on: https://gerrit.libreoffice.org/71066
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Was broken in d077b19a.

Change-Id: I5f0e0ca7c60f0f09381ee7eebd7d49d5533e07af
Reviewed-on: https://gerrit.libreoffice.org/71145
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>

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

For some reason, we have never exported the default column width
to XLSX, although we have such export for XLS. This led to bugs
like tdf#100946. Workarounds applied to those bugs have made LO
to export columns which shouldn't have been exported, abusing
"customWidth" attribute in XclExpColinfo::XclExpColinfo depending
on if the column has size different from an app-global default;
after that, sheet-local default was determined, and then columns
which have mbCustomWidth set (i.e., different from app default),
as well as those different from sheet-local default, were stored.
Effectively, the hack had disabled the removal of defaults from
maColInfos in XclExpColinfoBuffer::Finalize. We even had unit
tests explicitly testing that we export those columns that Excel
skips. The effect of that is not only unnecessary data in the file;
the data was actually wrong (customWidth actually means that the
width was edited manually by user, even if equal to the default,
thus changing Excel handling of the column); and also Calc
initializes all columns to the right of last used column for such
a file. Only in case when app-global default happened to match
sheet-local one, columns would have properties allowing them to
be removed from maColInfos in the end of XclExpColinfoBuffer::Finalize,
which still resulted in problems similar to the workarounded one.

This patch implements proper export of the default column width
to XLSX, thus partially reverting changes made for tdf#100946 in
commit 40d892a2. Actually, our
export to XLSX does not depend on the 5-pixel correction (see
ECMA-376-1:2016 18.3.1.81), since the exported default depends
only on most-used column width. XclExpDefcolwidth implementation
was edited to only take the correction into account when exporting
to XLS (to keep status quo; it's clear that XLS widths export
and import implementation is incorrect: some empirical formula
is used in XclTools::GetXclDefColWidthCorrection, that was
introduced in commit 555d7029 for
i#3006, that doesn't match any documentation, and changes widths
of columns in exported XLS - something to be fixed independently).

Change-Id: I227aca17e56247cbb839444717066a898987c4f1
Reviewed-on: https://gerrit.libreoffice.org/71132Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

b1118883 changed msfilter to use
GraphicFilter::ImportUnloadedGraphic() to lazy-load images
from the document. However, that function in some cases simply
reads the entire rest of the passed SvStream, which in this case
is the entire .xls file. And the document from tdf#124828 is ~50MiB
and contains ~4000 images => 100+ GiB memory required.

Change-Id: I74926383204ec642eabb28b62e2cf2e1ff8054a9
Reviewed-on: https://gerrit.libreoffice.org/71136
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

Meant to fix the build problems reported in the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2019-March/082340.html>
"Build failure with latest ICU 64.1".

Change-Id: I006b92f4737f5e56e50527dd954e8c0d339e75dc
Reviewed-on: https://gerrit.libreoffice.org/71143
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

This takes the loading time from 13s to 10.5s

Avoid expensive text-invalidation while we are loading

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

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

When reworking command U the shape 'RingOutside' was not considered.
Although it is a 'mso-' shape, it has angles in degree and not in
fixed-point number in its defaults. The patch removes in addition the
changes introduced by Symphony, which erroneously used total width
and height instead of radii for the ellipse size.

Change-Id: Iede8e346681796fb3e147dbcfaaa08ed8fe87c54
Reviewed-on: https://gerrit.libreoffice.org/70941
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>

Use-case here is .ods document with 16k tracked changes. For every
tracked change, Calc generates a formula cell. For every formula
cell, clipboard content is queried (via ScDocument::IsClipboardSource,
ScModule::GetClipDoc respectively). This is dog-slow on Windows

Therefore don't query clipboard content while the document is in
the process of being loaded. Instead return from ScDocument::
IsClipboardSource early and return 'false' because at this point
of time it can't be reliably determined whether this doc is a clipboard
source anyway

Change-Id: If5aa62cbfb62fb326a3c73b4d9be839127d3c03b
Reviewed-on: https://gerrit.libreoffice.org/71121Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

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