Change-Id: I42a773e2d5b8e4deeafa8eeb2785913db36a47d7
Reviewed-on: https://gerrit.libreoffice.org/70688
Tested-by: Jenkins
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/70766Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

Change-Id: I54c1f438a755267db0896637c79f915de9113f83
Reviewed-on: https://gerrit.libreoffice.org/71246Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

(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

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>
Reviewed-on: https://gerrit.libreoffice.org/71222

Regression from commit 961ba62d
(tdf#123032 sw, AddVerticalFrameOffsets: fix shape pos after mouse move,
2019-02-07), the vertical position of the bugdoc was too large, and
turns out Word only works with vertical offsets if there is already a
horizontal offset.

For example open tdf98987.docx in Word, remove the left square shape,
notice how the other square shape jumps up due to no longer working with
a vertical offset (while the doc model vertical position of the shape is
unchanged).

Change our layout, so that in case the AddVerticalFrameOffsets
compatibility flag is on (which was added to emulate Word's behavior),
we also consider the horizontal offset before setting the vertical
offset.

Also improve the SwUiWriterTest2::testTdf122942() test that asserted doc
model positions, which are now different (needed so that at the end the
layout position visible to the user is unchanged).

(cherry picked from commit 27894be9)

Conflicts:
	sw/qa/extras/layout/layout.cxx
	sw/qa/extras/uiwriter/uiwriter2.cxx

Change-Id: I8ac451efbacefdd3578b3a578260e7b2060c16a6
Reviewed-on: https://gerrit.libreoffice.org/71128Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>

Regression from commit 50223ea6
(tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31),
the problem was that vertical position of the shape was wrong after
mouse move, even if we attempted to take fly frames of the paragraph
into account. (Similar situation is when saving and loading the file;
which is much easier to test.)

Fly frames are created as the
text frames is formatted, and then SwTextFrame::CalcBaseOfstForFly() can
calculate the vertical offset correctly. But in the "move with mouse"
case SwToContentAnchoredObjectPosition::CalcPosition() was invoked by
the time the old flys of the text frame were already removed, but the
new ones were not yet added.

Solve the problem by formatting the text frame from
SwAnchoredDrawObject::MakeObjPosAnchoredAtPara() (if any of its validity
flags are set to false) -- this is expected to be safe, as the object
formatter is invoked by SwLayAction::FormatContent(), i.e. there is no
recursive SwFrame::Calc() call here.

(cherry picked from commit 961ba62d)

Change-Id: I95851874e3da3f50f304421537c6743e04bdfc7b
Reviewed-on: https://gerrit.libreoffice.org/71127Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>

Regression from commit 50223ea6
(tdf#98987 sw: add AddVerticalFrameOffsets compat mode, 2016-03-31),
SwFEShell::ImpEndCreate() was not adapted to call
SwTextFrame::GetBaseVertOffsetForFly() when determining the vertical
position of the inserted shape.

The call can be unconditional, the returned value is already 0 when the
DocumentSettingId::ADD_VERTICAL_FLY_OFFSETS compat setting is false.

(cherry picked from commit 4218caf1)

Conflicts:
	sw/qa/extras/uiwriter/uiwriter2.cxx

Change-Id: Iec6af5a6d1ff3466e08377853cc8ca84f33a76d1
Reviewed-on: https://gerrit.libreoffice.org/71126Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>

Change-Id: Ib736800544b9669e3708da0c01370af22cdf3e97
Reviewed-on: https://gerrit.libreoffice.org/69617Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>

The name attribute of dataField element was already read in
PivotTable::importDataField; and then it was ignored in
PivotTableField::convertDataField. ScDataPilotFieldObj had no
handler for name in its ScDataPilotFieldObj::[gs]etPropertyValue,
although it has [gs]etName for that - so this change puts pieces
together to allow to use the imported name correctly.

Reviewed-on: https://gerrit.libreoffice.org/71068
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 7f6a6664)

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

Otherwise, the empty string is used by Excel, so the field arrives
unnamed, disappearing from pivot table's cells upon refresh, etc.

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

Previously faux bold was drawn with setting a dictionary key
kCTStrokeWidthAttributeName and a value of the stroke width. This
stopped working because we don't use attributedString for drawing
anymore but we always use CTFontDrawGlyphs and draw the glyphs,
which doesn't have a way to set this attributes.

It took me a while to find a workaround (thanks to Apple's great
documentation), where we switch text drawing to fill and stroke,
and after that we can modify the stroke by changing the line
width.

Reviewed-on: https://gerrit.libreoffice.org/71012
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit eb560651)

Change-Id: I594fcb9c796a9c04ea8234a9938ca2f719706199

On Windows, gpgme expects gpgme-w32spawn.exe to be in the same directory as the current
process executable. This assumption might be wrong, e.g., for bundled python, which is
in instdir/program/python-core-x.y.z/bin, while gpgme-w32spawn.exe is in instdir/program.
In this case, if an operation in a python script requires initializing gpgme, it will be
interrupted by a modal warning box telling that gpgme-w32spawn.exe was not found.

If we can't find gpgme-w32spawn.exe in the current executable location, then try to find
the spawn executable, and inform gpgme about actual location using gpgme_set_global_flag.

Change-Id: Ie30a0d4a6666767e8c54f1bdc67b67570d6ea47a
Reviewed-on: https://gerrit.libreoffice.org/71014
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit cca68302)
Reviewed-on: https://gerrit.libreoffice.org/71036Tested-by: Mike Kaganski <mike.kaganski@collabora.com>

Also provide a default pivot table style for those tables that don't
have a style info. Let's use the style settings that Excel uses.

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

Handle %7c with small letters.
Make sure that the output parameter's content is not
affected by decoding.

Change-Id: Ie3faad2461815497c0edfb04a589fc57aeb7d66b
Reviewed-on: https://gerrit.libreoffice.org/70873
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
(cherry picked from commit f6dc5636)
Reviewed-on: https://gerrit.libreoffice.org/70984Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Change-Id: I3352bf9ade88bd86f7ca3d53238364216547d52b
Reviewed-on: https://gerrit.libreoffice.org/70830
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
(cherry picked from commit 2317ad57)
Reviewed-on: https://gerrit.libreoffice.org/70983Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Change-Id: Ic33646ec1af38d36c344fd7ec1ccfdcb838bc716

Change-Id: I04a3a22918ead008b560c2e1159747e8d28da404

Factor out the setFilterPropsFromFormat() also used by
SwVbaDocument::SaveAs2000() to a header file of its own.

Change-Id: I4bc9e1e420719a115036beb7e82a4ac3feac05f0

Bring White option to the first place,
to save toner on print as users tend to
click on the first option.

Change-Id: Id63c4402f8dc07a83eef69c3dfde3dd086c899b8
Reviewed-on: https://gerrit.libreoffice.org/70831
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
(cherry picked from commit d5b59b8d)
Reviewed-on: https://gerrit.libreoffice.org/70868Tested-by: Muhammet Kara <muhammet.kara@collabora.com>

Change-Id: I3fe30de8140dce3d81cdfae7d41e0bd465b1d5f4
Reviewed-on: https://gerrit.libreoffice.org/70879
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
(cherry picked from commit 2d85b75b)

After recent additions of 61c4f96d "Support
AdoptOpenJDK" and 41507db5 "Support Amazon
Corretto" to our hard-coded list, there is now reports that at least Debian and
Ubuntu tried to distribute versions of OpenJDK with the java.vendor propety set
to string like "Debian" or "Ubuntu".  Instead of trying to catch up with an
ever-growing hard-coded list, it is probably better to stop relying exclusively
on such a hard-coded list, and for unknown vendor values, try out whether the
SunInfo backend (which supports the "generic" OpenJDK) would be able to handle
the given JRE.  (For simplicity, assume that any versions of such JREs are
supported.  Our baseline is Java 6, and there are unlikely any older versions of
JREs from unknown vendors out there.  If this turns out to be problematic, we
could include information about problematic vendors after all, or add a general
check that JREs from unknown vendors are at least Java 6.)

Many functions in jvmfwk/inc/vendorplugin.hxx that used to take a set of
sVendor/sMinVersion/sMaxVerison/arExcludeList paramters had to be revised to
take a vendorSettings parameter instead, and
VendorSettings::getVersionInformation has been changed to return a
boost::optional, so that unknown vendors can be handled gracefully.

Reviewed-on: https://gerrit.libreoffice.org/70460
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(cherry picked from commit 3d27b2fa)
Conflicts:
	jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx
	jvmfwk/source/framework.cxx

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

there may have been changes not caught by undo to the object's
ordinal, so on use of RemoveObject (or ReplaceObject) call GetOrdNum
on the object to get its current position within its parent.

We can keep nOrdNum for the desired dest position within the parent
for InsertObject

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

The problem is that with LOK, the creation of Idle here causes a
deadlock when the dialog is being opened and its first paint is
requested.

No real idea what change now causes the problem (this used to work), but
given that the use of the Idle is a hack in the first place, let's use
the GetFocus/LoseFocus handlers instead, and act accordingly only when
the focus of the interesting controls changes.

Change-Id: Ib6c0267a064cb31438544e47fe3e0869b575ef7c
Reviewed-on: https://gerrit.libreoffice.org/70917Reviewed-by: Aron Budea <aron.budea@collabora.com>
Tested-by: Aron Budea <aron.budea@collabora.com>

Change-Id: I2c054ba672c7ab52a6e3f3f085823fd5015f0d62

... otherwise Excel would reset data formatting e.g. from currency
to plain numbers upon refresh.

Excel relies on per-field format setting in pivot tables, while Calc
takes fields formatting from source.

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

Change-Id: Ia5ca829877712b9814ce6eee392d8f1f23a7e97b
Reviewed-on: https://gerrit.libreoffice.org/70915Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>

IsPaintTransparent() is preventing to paint the background but
not sure why this is needed. removing this condition doesn't
seem to have any ill effects.

Reviewed-on: https://gerrit.libreoffice.org/70855
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 1e917af2)

Change-Id: I5ac54e208e4f1c9941beb4012aa44182d21dbed9
(cherry picked from commit 23d475949580d1b104f9bd34abe0441cfc0461ae)

This should prevent the crash - at least it did for me AFAICS.

Change-Id: I489264d8054e6577b948b0ab307c863d3140788a
Reviewed-on: https://gerrit.libreoffice.org/70755
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit 9f392d0c)

Change-Id: I41a9ff0d281d9032ddaafbbcb55352254a809efe
Reviewed-on: https://gerrit.libreoffice.org/70824
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/70880Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>

document"

Change-Id: I976318fe299306b65190b4f5ae0ed2565830c6f7
Reviewed-on: https://gerrit.libreoffice.org/70475
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Reviewed-by: Henry Castro <hcastro@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/70794Tested-by: Jan Holesovsky <kendy@collabora.com>

Users need an in-process copy of pdf to share
with peers and discuss the redacted areas

Change-Id: I68c16c6f09690a9d5cd2df191963107029e5ed88
Reviewed-on: https://gerrit.libreoffice.org/70863Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 06eb265d)
Reviewed-on: https://gerrit.libreoffice.org/70864

The message from clang-tidy is:
    warning: object destroyed immediately after creation; did you mean
to name the object?

The guard in
RequestHandler::ExecuteCmdLineRequests
comes from
commit cf333a87
Date:   Sun Jan 21 22:10:09 2018 +0300
tdf#38915: set cProcessed condition on any process outcome
and I'm sure it's intention was to set the flag on exit from the
function, not immediately.

Reviewed-on: https://gerrit.libreoffice.org/60183Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
(cherry picked from commit 867ee21f)

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

Users might accidentally move the main shape of
the page being redacted. Let's prevent that.

Change-Id: Ic0f3c2c819d1f974d203fa5fd70d57e5545ba8ef
Reviewed-on: https://gerrit.libreoffice.org/70843Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>

Excel expects the group field items to be in ascending order starting
from "<01/02/2010", then "Jan", "Feb", ..., then end with ">01/02/2020".

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

Might help in some cases in the customer application.

Change-Id: Icdc13780d4623e9df8bc057760c1295d7d6ffd61

Change-Id: Ica7448458ecc5e9adc802a288f72b1fceb709f79
Reviewed-on: https://gerrit.libreoffice.org/70724Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>

The slide-sorter is actually still necessary to apply/change
the master slide of a given slide, so we must enable it.

Change-Id: I3f59f58be76ab1c63453b4f6288044572800a556

Change-Id: I7554ba4afd28d7ea4f3ed6ba375d9765a89ef21c
Reviewed-on: https://gerrit.libreoffice.org/69618Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>

Change-Id: Ife85b3c728c59f7fb4e0184211efc9b652c5f4e7
Reviewed-on: https://gerrit.libreoffice.org/69615Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>

Change-Id: I4cb6ce6d961b4ba4d542c14cb37370788cf75e45
Reviewed-on: https://gerrit.libreoffice.org/69613Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>