Or do we already have the corresponding functionality somewhere, and
SbModule::Run() could be changed to use that instead?

Change-Id: I6f45d4a023f9f9d9a24ab6934117a712ccbe75e2
Reviewed-on: https://gerrit.libreoffice.org/55048Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Start a bit of work on that.

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

This adds a special treatment for fonts which rely on the win metrics
for correct line spacing calculation.

At the moment, only 'DIN Light' is known to need that treatment.

Change-Id: Idd9fd6f63083ab7a706e0cbcd33a947d4949d4e9
Reviewed-on: https://gerrit.libreoffice.org/53962Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Found with bin/find-unneeded-includes
A lot of fallout needed fixing, unfortunately

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

Need to incrementally migrate the remaining places (ODF, OOXML signing)
to CNG, then flip the default. SVL_CRYPTO_CNG=1 is needed till then.

(The testcase passes with and without the fix when SVL_CRYPTO_CNG is not
specified; it fails without the fix when SVL_CRYPTO_CNG is specified.)

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

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

part of the process of moving Bitmap usage to BitmapEx

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

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

There were a couple of problems apparent at this stage when using the
ooovbaapi things from a test Automation client (written in VBScript,
to be precise).

Accessing for instance the ActiveDocument property of an
ooo::vba::word::XGlobals instance worked fine. But properties of other
objects, like instances of ooo::vba::word::XDocument, did not work.

When attempting to access any property of an
ooo::vba::word::XDocument, the code ended up calling the hasProperty()
of SwVbaDocuemnt. That function is for checking a totally different
kind of "properties", namely named form controls. Why form controls
are con-fused with oovbaapi properties I don't know. Maybe it is
intentional and as expected when using the oovbaapi from the built-in
Basic interpreter in LibreOffice. Or then just an accident in history.
Still, surely it can't be changed, that would break Basic scripts
embedded in existing ODF documents.

Anyway, from an OLE Automation client, for instance when asking for
the Content property of an ooo::vba::word::XDocument object, we
definitely don't want any form control that happens to have the name
"Content". We want an object with two integer properties, Start and
End.

Make this work by always creating an invocation factory instead of
using the object itself. Pass the invocation factory's
createInstanceWithArguments() function an extra argument indicating
this is the case of use from OLE Automation.

In the Invocation_Impl class in the stoc module, when this extra
argument is noticed, set a new mbFromOLE flag. Modify the behaviour
slightly when that is true. I am not at all sure that this will work
in all cases, but let's see, at least for simple tests so far it had
the intended effect.

Another issue was that looking up these properties was case sensitive.
This is wrong at least from languages like VBScript. Use the mbFromOLE
flag also to affect the case sensitivity behaviour.

Maybe I should simply make sure that _xDirect is null in the
Automation case? _Direct (a reference to an XInvocation) being
non-null probably means that we are using the document interface's own
implementation of XInvocation, which is probably always wrong in the
OLE Automation case. (Just see the SwVbaDocument implementations of
hasProperty() and invoke(), for instance.)

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

Change-Id: I1cb0c9bfca7ebcf8de96ef25554a41d52b9d7df5

Change-Id: I82173e7ab3f374e014b2ade060f44aa97451e439

The tables in the test .ODT contain a cell with text "With merged cells".
The text is supposed to wrap, so that cell height includes the two lines.
The width of the cell is 32.72 mm. When it is exported to .DOC, due to
rounding errors, the width becomes 32.76 mm. It happens that the text
width is too close to these numbers, so depending on rounding when text
layouting, it may start to not wrap in .DOC.

This just adds an extra space character to the line, to stop depend on
rounding errors.

This also reverts commits b2a05316 and
a30a36b3, which had workarounded this
issue.

Change-Id: Ifdb7a042f78a1a3cce3a385e9db865a1b8c7b134
Reviewed-on: https://gerrit.libreoffice.org/53906Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

Fixed by my previous commit.
This reverts commit 27cc0064.

Change-Id: Ib64e7341251d848b4db0dbb1f58c4fcef51437ed

When calc_tests runs test_tdf53482_Range_contains_column_headings_file()
with Calc's threading enabled, it ends up calling ScInterpreter::ScProper()
from threads, which calls to CharClass. And while CharClass tries to be
thread-safe (guessing from the mutex usage), it forwards calls to i18npool's
CharacterClassificationImpl and cclass_Unicode, both of which aren't
thread-safe. Which makes thread safety of CharClass itself pointless.

Since CharClass already acquires the mutex anyway because of getMyLocale(),
just extend the duration for the entire call, which hopefully shouldn't
make that much of a difference.

Change-Id: I544b34d7e58c4a901f3b6e3a3ff52156b9e320a8
Reviewed-on: https://gerrit.libreoffice.org/54999Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Luboš Luňák <l.lunak@collabora.com>

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

Project: dictionaries  6c85a19c887b6147ec7d3a600b51cb2a44284fa2

Update Croatian dictionary to version 2.1.1

Change-Id: I8425ab128d04d428ccc99cb6c8abe2635292f143
Reviewed-on: https://gerrit.libreoffice.org/53578Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>

...which was apparently unused (under its original name SF_TABLEFORMAT) ever
since its introduction in 571f1500 "Unix PS-
Print Environment".  (Not sure what its appearance in the comment to AddTable,
also there since that introductory commit, was ever supposed to mean.)

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

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

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

so don't create the pages until the first execute

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

since...

commit 9fa32e5d
Date:   Wed May 16 11:54:52 2018 +0200

    fix leak of HelpListener_Impl in SfxHelpWindow_Impl

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

Change-Id: I29bdf088c83ce69152d5c3edee2c855bfece4585
Reviewed-on: https://gerrit.libreoffice.org/55019Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Zdenek Crhonek <zcrhonek@gmail.com>

Change-Id: Ia307836869e54ab8f5a9727c913979cee4f259f4
Reviewed-on: https://gerrit.libreoffice.org/54868Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@libreoffice.org>

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

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

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

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

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

Create the objects on offer to Automation clients lazily

It would be silly to create the ooo.vba.word.XApplication in every
LibreOffice instance, even if no Writer functionality was going to be
used at all in that process.

I did not have to do what the old FIXME said, "make Application a
proper service", whatever that means.

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

Change-Id: I84644cddd8a318a2af23780ada9afc26fe23a9fe
Reviewed-on: https://gerrit.libreoffice.org/54719Tested-by: Jenkins <ci@libreoffice.org>
Tested-by: Rene Engelhard <rene@debian.org>
Reviewed-by: Rene Engelhard <rene@debian.org>

... and handle opens___.ttf like unowinreg.dll
(-> download.lst/$(TARFILE_LOCATION))

Change-Id: Id4723fb15c4b4b04133dedf97b1262441baa4756
Reviewed-on: https://gerrit.libreoffice.org/54938Tested-by: Rene Engelhard <rene@debian.org>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Rene Engelhard <rene@debian.org>

We get that when an Automation client wants to enumerate an object
that is a collection. We need to create an IEnumVARIANT object and
return it (as an IUnknown).

I wasted days on trying to implement this IEnumVARIANT object using
the same twisty maze of helpers, wrappers, UNO conversion utilities,
etc as used for the other stuff here. The other objects have both UNO
and OLE personalities. Could not figure out how to do it.

Then I decided to just do it brute force, following some sample code,
not bothering with any UNO personality at all for the IEnumVARIANT
thing, and it worked right away.

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

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

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

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

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

According to 1ecdc7aa it is really needed only for resolving fields,
so if there's no field, simply concatenate the contents, as used to
be the case before that commit. This should be faster and also safer
in the case of Calc's threading enabled.

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

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

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

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