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

Change-Id: I8cc89c66eb1c3f09e02ba312e6ea8c9379ff8a4d

Commit c2ccd20c introduced 0 as a valid
value for page number offset in sw core.

Unfortunately the table dialog was not changed then; previously
page number 0 would do automatic numbering, but since then 0 was set as
the offset, and once you have a 0 offset there's no easy way to remove
it, you have to remove the whole page break.

* change the label before the text number edit widget to a checkbox
  that disables the edit widget
* keep the id "pagenoft" so that translations still work
* set initial value to 1; 0 is a really bad default since we can't
  export it to ODF
* add a little bit of left margin so the line is indented below the
  upper line

Change-Id: I70cf5a66d4191acd2c19b3d0a83609e2b348a886

Change-Id: I1fbc1f7ec14c8133fb8fcd3532d5d551dcc7ddfb

http://crashreport.libreoffice.org/stats/crash_details/524d28fb-4fd2-4d11-83b1-1360b5ab5068

Change-Id: I19a13f751b5cf000c9938ff991d7d44bba0a4de7
Reviewed-on: https://gerrit.libreoffice.org/34756Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>

Change-Id: Icaf1de556ae20027e27321750197ed574b508435

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

cause it grows to fit if its a resizable stream

Change-Id: I28b42becdfc8eb591d19d2512cdc1f1ec32c3bbe

Change-Id: I46b84ab4cb9cc5d25b6cb60241fcc8a65e449886