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

Change-Id: I8647c6e820b4bac795e87d538eba822fac7ddbe7
Reviewed-on: https://gerrit.libreoffice.org/54644Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

Like what has been done with left distance to border, so that the
ruler handle reflects the setting.

Change-Id: I4ed920280aafc537ba3068f0f666778c2d723b6b
Reviewed-on: https://gerrit.libreoffice.org/54618Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

SvxProtectItems were used to protect size and position of the rulers in
Impress/Draw but weren't really activated because they were missing in the
sdi of the view shell.

See also: DrawViewShell::GetRulerState() in drviews3.cxx.

Change-Id: I576932fb45acd996a3b6f3045dcbc131b7316ece
Reviewed-on: https://gerrit.libreoffice.org/54616Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

Use the cell boundary to decide correct SvxLRSpaceItem values.

Change-Id: I1906eaf34a7ff5f852b729114371ddb5387692d3
Reviewed-on: https://gerrit.libreoffice.org/54615Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

Change-Id: I7ddce601bd7204e5696b601c6f8cd16619017aa2
Reviewed-on: https://gerrit.libreoffice.org/54881Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

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

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

Change-Id: Iab17340f57cf8b116d2f058661dabd3a95fb61d2

For Automation clients. Provided in extensions/source/ole/servprov.cxx
for an instance of ooo.vba.word.Application.

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

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

Change-Id: I48d78fb86c2604040b3d0c2d207aae410faf4870

Change-Id: I7684d4747c4977103fcc3dca62f5d1c28a0836bf
Reviewed-on: https://gerrit.libreoffice.org/55056Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>

Instead, never participate in the macOS system full-screen mode. There
is just too much complexity involved, and the way LibreOffice works
really isn't prepared for the concept of windows having the option
from a system point of view to being full-screenable or not.

This means that the green bubble in window title bars changes from
being a (system) full-screen toggle to being a maximize/restore
toggle. Sure, the "maximize" concept also probably can be confused
with LibreOffice's own full-screen concept.

For instance, the Start Centre window is not expecting to be made
full-screen. Still, when you from the Start Centre open a Writer
document, it is the *same* window that is re-used as the Writer
window, and then suddenly should be prepared to handle going
full-screen.

Also, it is up to each separate kind of document window whether it can
be made full-screen (from the LibreOffice point of view) or not.
Writer windows can, but Impress windows can't, for example. The
View>Full Screen menu entry is added separately each case.

Maybe I will come back to this mess later, or not. Anybody else is
welcome to have a go, too, of course.

This reverts commit 4b42fd7e.

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

As VS2017 so eloquently puts it, "Warning STL4017:
std::wbuffer_convert, std::wstring_convert, and the <codecvt> header
(containing std::codecvt_mode, std::codecvt_utf8, std::codecvt_utf16,
and std::codecvt_utf8_utf16) are deprecated in C++17. (The
std::codecvt class template is NOT deprecated.) The C++ Standard
doesn't provide equivalent non-deprecated fu tml_ nctionality;
consider using MultiByteToWideChar() and WideCharToMultiByte() from
<Windows.h> instead. You can define
_SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING or
_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have
received this warning."

So VS2017 actually recommends using platform-specific API instead of
standard C++ API that is or will be deprecated but has no standard
replacement. Insane.

Note that it is not enough to define that
_SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING just right where you
are including <codecvt> because "for all of the warning suppression
macros, you must define them before any C++ Standard Library header
has been included (both <vector> etc. and <cstdlib> etc.)" as
mentioned on
https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals-and-deprecations/

So define it in the single file that includes windowsdebugoutput.hxx
for now.

Change-Id: Iecd9702502ce3b33013d6799c618d6b98d803c3e

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

Seems that the fix is not complete: e.g.
https://ci.libreoffice.org/job/gerrit_windows/7272/console

This reverts commit b7da22a6.

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

Otherwise there is a race condition when calc uses threading, and lp#390983-2
sometimes crashes.

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

To insert separators, literal strings between digits and other,
the formatter operates backwards on the string obtained from
doubleToUString() cleaned of the decimal separator. The number of
decimals returned by doubleToUString() may be less than the
decimals of the number format as entered by the user, which lead
to separators inserted at wrong positions. This wrong behavior was
triggered respectively made more obvious by

    commit 0f6203ed
    CommitDate: Wed Jan 13 14:47:57 2016 +0100

        tdf#96918 display accurate integer double values up to (2^53)-1

which for integer values returns at most 15 decimals ('0' in this
case).

Before operating on the decimals' part ensure that the number of
decimals matches the digits requested, and if shorter append
trailing '0' characters for the required amount so the separators
(and other strings) are inserted at the correct positions.

Change-Id: Ic02652699ea7d6fae3b2b3348f6f7d183319e043
Reviewed-on: https://gerrit.libreoffice.org/55039Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Signature lines is no longer ooxml specific

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

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

Apparently the preprocessor leaves in the #define but expands the uses,
so all macros are reported as unused.

Change-Id: I064a8852ad1080c22440c2b0d05c9dfddcec45f1
Reviewed-on: https://gerrit.libreoffice.org/54992Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>

Change-Id: Ife4040b181f0688d67de4a2a36e2d2f810e4fce5

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

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>