Change-Id: I9b4f740e1c53de0ee90c3299970f774ace67323b

This changes the lpsolver test to explicitly test the available
linear solvers we have - either CoinMP, LpSolver or both. This
prevents that a newly added solver will be automatically tested
as it can have a different behaviour for the tested input values.

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

Change-Id: Ic91bb15cafa97538a61247660044c1af57b59d84

Change-Id: I72a2d8ce47059f9af65d89fbdcc09d96c40cb79b

Change-Id: Ie8cef4375608df160b383ff74c32838f00e60aba
Reviewed-on: https://gerrit.libreoffice.org/34777Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>

Change-Id: I090cec1f311be5e5a34e208d066925b294310e43

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

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

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

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

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

Change-Id: I01c7ebf10831a27eaab55c2082cbe0a0f28bda1f

Change-Id: Iea7d436a78336de150b3d3ae317b99b554fb8657

Change-Id: I7a3f7233018e76208f80e47eb176c2879e943e47

Change-Id: Ief236828f564ff81bf3a415127413b6cc72fd70d

Change-Id: Iaca54d62a48711a7763cac98c6f303b952b2da29

and RLE8/RLE4 compression with wrong bitmap depth

Change-Id: I7e580cb119e90262a88c57b86f562eaba81c4944

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

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

...from 9ca8a63f "Use consistent integer types
in the SwRedlineTable interface".  This all started as an attempt to reduce the
number of places a to-be-committed improved loplugin:loopvartoosmall complains
about.  Lets see where it ends...

SwRedlineTable::size_type is now the size_type of the underlying std::vector, no
longer sal_uInt16 from ancient times.  I tried hard to find all places that are
affected by this change, changing types of affected variables and non-static
data members as needed.  Some notes:

* The original code used USHRT_MAX as a "not found" value.  I replaced that with
  a new SwRedlineTable::npos, of type SwRedlineTable::size_type but still for
  now of value USHRT_MAX.  This should eventually be changed to something more
  sensible, like std::numeric_limits<SwRedlineTable::size_type>::max() (which is
  best done after we have constexpr support in all toolchains, so that npos can
  be constexpr).  It is important that the value of npos is towards positive
  infinity, as many places in the code use

    for (i = f(); // may return npos
         i < table.size(); ++i)
      table[i] ...

* There are some borders where values of SwRedlineTable::size_type are converted
  into different types, for various reasons.  But all of those other types
  should be large enough for practical purposes (at least 32 bits wide):

    MakrEntry::m_nIdx: long int
    SvxRedlinTable::InsertEntry: sal_uIntPtr nPos
    SwRangeRedline: size_t
    SwRedlineItr: sal_Int32
    SwVbaRevision::GetPosition: sal_Int32
    SwXRedlines: sal_Int32

* .uno:TrackedChangeIndex= transports textual representations of such values.
   libreofficekit/qa/gtktiledviewer/gtktiledviewer.cxx treats them purely as
   strings, while SwTiledRenderingTest converts them to int.

* TODO:  The one place I'm unsure about is SfxUInt16Items with IDs
  FN_REDLINE_ACCEPT_DIRECT, FN_REDLINE_REJECT_DIRECT, and FN_REDLINE_NEXT_CHANGE
  in sw/source/uibase/uiview/view2.cxx.  For now, I kept those as
  SfxUInt16Items and take care to "map" USHRT_MAX to npos when reading from
  those items.  But I have no idea where instances of those items would actually
  be created, and what it would mean to change those items' types?

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

Change-Id: I2fb82e3c5a9b26b1016cf99e943cf0cc30225495

This requires one function call / row only, cross-platform and works
with OpenGL enabled as well.

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

Change-Id: Ie35617997845de25af9e528668bce4c332ac408a

Change-Id: I1e4dc5f474b229d4d68d3fc34bc23c88767e5e50

instead of looping

Change-Id: I7b8c1663e303449302e0b96dc5b483367c2a52ba

This service is only used in xmlsecurity and it's a wrapper around two
free functions in the same module.

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

instead of needlessly catching the exception that
comphelper::getEnumAsINT32 generates, let's just call the same function
that comphelper::getEnumAsINT32 uses

Change-Id: Ibc7d79cc15c13d4124f5bd62a038804209cf5b07

no point in redeclaring an existing enum exactly

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

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

Change-Id: Id0883060acf2ca73af5cce56e1cf9021c2fb121a

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

DataFlavorExVector is a std::vector<..> typedef.
remove odd void pointer in BrowseBox.
return const references to keep getter const qualified.

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

because it cannot happen unless the invariant about TG::UnOper is
broken.

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

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

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

Change-Id: I287ec575d95ff950097a255abbcd0d3304c04a56

Change-Id: Iaa349921972bb19b40bf68c6a3b0c7128cff4b8d

when generating a new one, otherwise on exporting the same table
twice to two consecutive .doc footnotes will think the second
export of the table is a level lower because it will find it
in the map and

WW8TableNodeInfo::Pointer_t WW8TableInfo::insertTableNodeInfo

does pNodeInfo->setDepth(nDepth + pNodeInfo->getDepth());
using the cached pNodeInfo depth and not a new fresh pNodeInfo of
depth 0

Change-Id: I7aa7ac6a19814910c1d19d78f04cfd9886c444c5

Or could it be that some external scripts insist on running
LibreOffice.app/Contents/program/soffice? Or some instructions talk
about that pathname?

Change-Id: I99e2b2636971c7ee8de09a9e42df9f965eeec5fb

Project: help  e7999c35fd7460118469142420c7d39ba5562222

tdf#77111 helpcontent: adapt "Text flow" tab page help

Replace obsolete description of "0" page number.

Change-Id: I1881bca456d94af74060e1e3b92e043255c9e702