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>

Layout is still not yet correct right after the import, though.

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

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

Regression from 7a9f6df7

ERROR: The following errors occurred in packaging process:

ERROR: Source for LICENSE.html not found!
ERROR: Could not copy  to
 /Users/gerrit/lode/bibisect/core63/workdir/installation/LibreOfficeDev/dmg/
install/en-US_inprogress/LibreOfficeDev_6.3.0.0.alpha0_MacOS_x86-64/LICENSEs/LICENSE.html No such file or directory

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

to find more places we can elide the OUString() constructor at call
sites

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

The declaration in BarChart.cxx is particularly suspicious, because it
was using a < for the KeyEqual template parameter.
Been there since:
    commit b2c3233e
    Date:   Thu Dec 21 20:08:33 2017 +0900
    chart2: suspend/resume setting rects dirty for 3D shapes

comphelper::OInterfaceCompare is no longer necessary

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

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

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