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>

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

This reverts commit 220ce1a5.

Including a header file of another module and even a module that is above is a no-go.

Change-Id: I3c8107d8c667c34259bdfee9d83afb2651f5e11c
Reviewed-on: https://gerrit.libreoffice.org/71142
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>

comment from Miklos:
 > Won't this do a comparison of two null-terminated strings, while
 > the strings here are utf16, i.e. abc is a\0b\0c\0? That would mean
 > in practice you compare the first char only.

introduced in
    commit 003d11f4
    Date:   Sat Apr 20 08:32:33 2019 +0200
    tdf#81765 slow loading of .ods with >1000 of conditional formats

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

regression from
    commit 1a5b12aa
    Date:   Thu Apr 18 15:13:19 2019 +0200
    optimise find/insert pattern

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

FillInfo is called more often than Initialize, so we've ended up
with multiple AcceptChgDat strings

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

because we know all these get a label/tooltip set at runtime

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

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