Previously, for an XML like this:

    <sharedItems>
        <d v="2017-07-10T09:11:02"/>
        <d v="2017-07-10T09:11:03"/>
        <m/>
    </sharedItems>

the call like

    int pos = getXPathPosition(pDoc, "/x:sharedItems", "absent");

gave 3. That could result in mistakes, when a test would assert
on position "3" for a child element which name is mistyped.

I made such a mistake when creating a unit test trying to assert on
a position of the last element, and writing its name as "x:m", like
in rXPath itself; the return was 3, and I initially wrongly assumed
that the return is 1-based (like in xpath bracketed expressions).

rChildName made const OString&, for consistency with rXPath, or with
rAttribute in getXPath: child name is just a part of a longer xpath.

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

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

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

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

... so that 2017-07-10T09:11:02.999999... becomes 2017-07-10T09:11:03,
not 2017-07-10T09:11:02. The latter created duplicated items in pivot
table cache previously.

TODO: check what to do if the times are actually different by 100 ns?
What Excel does then? Should we increase cache item precision?

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

Move XPropertSet Java tests to C++ for ScCellSearchObj.

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

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

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

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

Just because this image is transparent, does not mean it is equal to the
other image.

Similarly, just because this image has transparency color, does not mean
the other image has valid transparency color.

Also move the cheaper mbAlpha check before the more expensive
ShallowEquals check.

there since
    commit 8ab086b6
    Date:   Mon Sep 18 16:07:07 2000 +0000
    initial import

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

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

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

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

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

Change-Id: Iaa20611ccde1d53cd85db63cbdab450c1622a303
Reviewed-on: https://gerrit.libreoffice.org/71601Reviewed-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: andreas_kainz <kainz.a@gmail.com>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

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

Reduced svg size

Change-Id: Iccfe353d33f7c78600a1cdf24fd67038831fc692
Reviewed-on: https://gerrit.libreoffice.org/71562
Tested-by: Jenkins
Reviewed-by: Matthias Freund <matti_lx@secure.mailbox.org>

Commit a51b7a1c (tdf#103831, tdf#100986:
Force using GDI when needed, 2017-03-03) noted that the DirectWrite text
renderer doesn't support vertical text, add initial support for this now
by extending the DirectWrite transform matrix to do rotation as well.

This is initial support, as it can be improved in two ways:

- vertical text is not cached

- only vertical Latin text is handled, which wants rotated glyphs (vs
  e.g. Japanese text that would not rotate the glyphs)

With this, the "unreadable" text in the bugdoc's chart is on par with
the the GDI rendering.

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

Was recently added in 453e6fb7

Here this goes into an infinite loop, at least it doesn't finish in an
hour; Miklos claims it's due to missing fonts, let's just remove the
test for now, the file will still be tested by crashtesting.

Change-Id: I8acd05e9428ca25d1255b9f14ca56c7a9f5d4f00

If an adjust value is not directly bind to a handle parameter but
via formulas, the calculation of the adjust value depends on the
individual shape. The error was, that one calculation method was
applied to any OOXML-shape. User noticed, that handles did not
stick to the position, where they are released but jumped to
unexpected positions. The patch calculates guide formulas backwards
to get an adjust value. The patch solves the problem for preset
OOXML-shapes until some day a general method for any shape is
implemented.

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

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

so it can shrink to its optimal size

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

This was removed today.

Change-Id: I07e7515d0d4b63721c6f80193917a9e1c5f1f09b

Effectively revert commit 1ecca673.

There are some documents that aren't formatted correctly.

Change-Id: I4b0cf6313c249a0ed916c2630cd5194d809bfb48

SwSaveSetLRUOfst would leave only 50 cache entries available for the
CalcLayout() to use; apparently it's not enough for this document.

The difference between the 1st loading/layout and the 3rd loading/layout
of the document is that in many paragraphs the cache entry is missing,
because the entires of the previous loads were clogging up the cache
and were preserved here, and the cache only has 50 available entries;
if enough entries are available, everything is positioned properly.

The idea with the 100 entries per visible shell actually comes from the
CVS initial import, where there was a comment suggesting that; but the
corresponding parameter was actually unused and removed in
7c704c78.

Ideally we'd have time to investigate why a missing cache entry causes
the wrong position...

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

Apparently nothing else would remove the entry, and without SwTextFrame
it's not accessible any more.

If the entry was recently used, then the SwSaveSetLRUOfst usage in
SwViewShell::CalcLayout() will preserve it instead of giving the cache
entry to a new frame.

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

...similar to handling breaks before shapes in lcl_startShape.

Three different examples found to create/split a paragraph.
Which one to use? (addDummy, m_bIsSplitPara, and
lcl_startCharacterGroup). SplitPara is not good because the
paragraph properties probably should not be copied to the
dummy paragraph (like numbering for example). Slightly
modified the lcl_startChar example to ensure that the dummy
paragraph doesn't steal a part of the properties, but is
only default properties plus page-break.

This doesn't export very well, so roundtripping is very poor.

Research Note: There exists a compat flag showBreaksInFrames
(Display Page/Column Breaks Present in Frames)
"This element specifies whether applications should
honor the presence of page and/or column breaks which are
present within the contents of paragraphs which have been
defined as frames using the framePr element."
--Currently, LO does nothing with this flag. Probably too
exotic and irrelevant (word 2003 era?).

No existing unit tests found that have isSet(pg_brk) frames.

Change-Id: I29f815355401c7af8b347a3ed9d0298bc9b27b93
Reviewed-on: https://gerrit.libreoffice.org/71255
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

In this case we are explicitly interested in textboxes,
but any fly that accepts XATTR will now use that and skip
the old RES_BACKGROUND.

In the case of textbox import, the properties were being
converted into RES_BACKGROUND and then back to XATTR again.
Just copy the XATTR properties to the new FlySet instead.

The ability to import XATTRs into a textbox was added to LO6.3
with commit 15819181

Change-Id: Ib65b3d9097d0a56dbe205b419d052af53d0132c8
Reviewed-on: https://gerrit.libreoffice.org/66331
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

1. Fix target path for the embedded media. Move the media
file to /ppt/media ( was /media ) and use the relative path
../media for the target path when adding the relation. This
is necessary for MSO to play the sound.

2. Write timenode id for the start or end conditions if the
animation node for the begin event or the end event is
available. Events like BEGIN or END has to refer a timenode.
Without specifying referred timenode in start and end
condition, Impress will not activate the audio node after
importing the document.

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

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

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

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

gtk listens to the selection so realizes that the GtkEntry selection
is not the desktop selection anymore and drops the visual selection.

But we're relying on the visual selection to know what part of
a multiselection we are modifying

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

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

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

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

It can happen that a bitmap is 32-bit (made from a VirtualDevice)
but we can't even create a 32-bit bitmap ourselves. In that case
we can only create a 24-bit, but now we can't use the fastpath
anymore as the bitdepth of source and destination is not the same.

Fix this by making sure the general scaler will be used when
source and destination bitmaps don't have the same bitcount.

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

some hard to reliably reproduce crashes when drag'n'dropping slides
in slide sorter in Impress can be tracked down to null drop target.
Not every SalFrame is registered as drop target, so let's accept
drops (QWidget::setAcceptDrops) only for those frames that are.

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

* Update dictionaries from branch 'master'
  - Update Thai dictionary: corrections, UTF-8, and over ten thousand more words.
    
    Change-Id: Iea084036516e727af2f70729bd7484fb9cbdad90
    Reviewed-on: https://gerrit.libreoffice.org/71523Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
    

Revert part of
    commit dd8d5e57
    Date:   Mon Apr 29 11:18:21 2019 +0200
    improve loplugin:stringconstant

sberg's original gerrit comment:
but there can also be other problematic overloads for parameters like
`void const *` or `std::string_view`.  I'm not sure this change is worth
the potential false positives.

and continuing IRC discussion:
<noelgrandin> I'll revert the compilerplugins/ part
<sberg> noelgrandin, my main concern is that /if/ somebody eventually
runs into such an overload situation, it's really hard to get the
warnings/errors fixed for those people, short of going into the plugin
itself

Change-Id: I4916ce8943c4319d7ef9084e22d6a0eeb430b15c

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