Change-Id: I81e97c5f720535b33dd3ce72d01151765e4e93a0

It is more readable and more efficient as a bonus.
See: https://goo.gl/jsVAwy:

Change-Id: I5aa95161f9284ce40354316d6d01be97e60241e4
Reviewed-on: https://gerrit.libreoffice.org/26736Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

This fails with commit 7d76bb25 (vcl:
add graphic export-as-pdf filter, 2016-06-24) reverted.

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

Change-Id: I185852a738bac10dc6d331afccfcbc7ae1225cb1

Change-Id: I31053ae472f74eaf3a86159a273424174329d0bd

Change-Id: Id07b37629eb2a0b6d33297bffcf86d41c5d6fbe2

Change-Id: Ida89fa8d35d1e22c706bc3703d2397b572bc01b5
Reviewed-on: https://gerrit.libreoffice.org/26752Reviewed-by: Akshay Deep <akshaydeepiitr@gmail.com>
Tested-by: Akshay Deep <akshaydeepiitr@gmail.com>

Change-Id: If3b81de299eca8b398a65534d1b201bf38daf19f
Reviewed-on: https://gerrit.libreoffice.org/26733Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>

Since 23e5540a we can use
GetDoubleOrStringFromMatrix() and check for SC_MATVAL_BOOLEAN.
Only if transported of course..
If not, then even a {FALSE,FALSE,FALSE,...} result is better than the previous
{FALSE,TRUE,TRUE,...} for any array sequence where all TRUE results resulted
from the previous call to ISLOGICAL() ...

Change-Id: I879e0cbc6557e73ac24713267b5122f923500501

None of the callers checks for SC_MATVAL_VALUE but all use IsValueType()
instead, which includes SC_MATVAL_BOOLEAN, but we may want to explicitly
identify SC_MATVAL_BOOLEAN.

Change-Id: I6737eb2909c819b6c54f7e62cf8ebfc12af14fea

Change-Id: If9ce8a094af878497e980cdcfaf11604d613e5b8

Change-Id: I7cb43f915565dadd611b90ee30373e472f97efb5
Reviewed-on: https://gerrit.libreoffice.org/26748Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

when a first torn off instance was opened just before the second one
and then the second one sends focus back to the first when its popped
down.

The second one listens to losing the focus and disposes itself which leads to
dereferencing deleted stuff.

So add a reference count to the places these tear offs call popdown so its
still gets disposed but not deleted during the popdown and then protect against
members being disposed with a enough checks to get back to safely

Change-Id: Id5f8eb4771df36305e308a2a9a5035018948f121

Seems to have changed from Fedora 23, where it was just "screen", to 24.

Change-Id: I9078c337093d12d62e9afe10b1f02aaf346d4b43

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

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

Change-Id: Ice084d8c0651b1b08e8e8cce6f4a6f1c09e8dd3e

Change-Id: Icb8761e5ff89e1c0e0e034a751fe9a50ad5ab90a

Change-Id: I902acd90797ab26304bc5b239b862cae9f3075ef

If TextBox contained text that is larger than the box, and
autofit was off, and autosize was off, and full width was off,
then text always aligned to box's left top corner, regardless of
text anchor setting.

Related problem (i103454) was fixed in 2009 by Armin Le Grand, but
only for full width text. This patch extends the scope of that fix
to correctly process other cases.

The fix introduces a new compatibility flag:
AnchoredTextOverflowLegacy
If it is true, then old behaviour is retained.
It is always false for new documents and imported documents.
When opening existing ODF documents, it's true by default, unless
it is explicitly set in settings.xml.

Unfortunately, I couldn't find a way to access the document model
from any of SfxBaseModel::load() or SfxObjectShell::DoLoad, where
it could enable setting the compatibility flag universally when
loading own format. Instead, I had to do it individually in each
of SfxObjectShell::Load() implementations.

Unit test is included.

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

...where NmaedDecl::getQualifiedNameAsString (which is expensive and bad,
anyway) apparently returns something other than "(anonymous namespace)"

Change-Id: I05ef96665c48f8f596dd0d317388e91a75b8307b

const bExternalModel was already set to xModel.is(), and xModel
hasn't been modified since then.

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

Function returned different results than Excel does because of missing constraints.
Added constraints are all defined in ODFF1.2 for AMORLINC.

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

Function returned different results than Excel does because of missing constraints.

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

This allows an unnecessary GDIMetaFile -> WMF -> GDIMetaFile roundtrip,
and also avoids the odd black border at the bottom / right of the
preview metafile in the PDF import-as-graphic filter.

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

Change-Id: Ie2859f03b31c57deb7fd0deba3285f782e33b239

Change-Id: I0d9d27715ed987b6cdcc88ac6ce000083d184e90
Reviewed-on: https://gerrit.libreoffice.org/26742Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I264fe688519b8b2173d5cccd8a453847a7fb89d9

There should be no need for it as far as I see. Possibly it made some
sense back when we thought we could use OpenCL for operators and
functions that are supposed to ignore the case of strings they
handle. But we hopefully should never try to use OpenCL for string
data nowadays anyway. And actually, the case-folding ended up
affecting strings handled by the so-called software interpreter. For
the tdf#75387, the sample sheet worked fine when OpenCL was enabled.

Change-Id: I1c170ebf09551fea0964f394cdb3c65079672257

Also make changes to make loplugin:staticmethods happy

Change-Id: Ia55d063c0fa5a1d9392e09f23ebb1266f46745b9
Reviewed-on: https://gerrit.libreoffice.org/26740Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>

Change-Id: Ia10a76a98a63c6ea3b516d9146281f672b213ab3

Change-Id: Idf91592e6cf34b5591f221c3c5bdc937bbe46014

..."tdf#97527 - vcl: reference-count Menu"

Change-Id: I47457205ae99025d2ca13965dcf2fac79962124a

Change-Id: I5b36d48749faaab7c1280b5d086bf0d65a313469

Change-Id: I641ebdd7610289a872dd0c8de9b297e5e6ba0b45
Before: notebookbar was closed even if exit was canceled by user

Change-Id: Ia0d8f463a4dba9ec63aa0159441e3e607dd3bf5e
Reviewed-on: https://gerrit.libreoffice.org/26738Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>

Use case is to insert a pdf file in Impress, then choose Save from the
context menu of the image. On one hand, for some reason only bitmap
images can be saved, so add an exception for the graphic-with-pdf case.
SVG is not affected, as it counts as bitmap with its PNG replacement
image, it seems.

On the other hand, copying the GraphicObject around triggers
swapout/swapin of the graphic, and there the original pdf data was lost,
fix that.

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

I see hundreds of the "'operator *=' detected overflow" warnings on
Windows doing perfectly normal things. The call site for those
explicitly checks anyway for an invalid (overflowed) result.

(Sure, there might be other call sites where the warning possibly had
some degree of usefulness because an overflowed result is not checked
for. I am willing to take the risk.)

Change-Id: Ie88ad11d159ee7aa505c22633a7e2cda1246ff31

Change-Id: I6e5a1c33eeb5eb139f12d4a9d696c53ad65a3af7

Change-Id: I5307c3ca3ebef72a08055e9389bc53e760d4178c