Change-Id: I1f53c644120180c730706cab8b969f36fa4023be

We calculate the scanline size wrongly when writing a PDF so the
image is not exported correctly. BitmapAccess already has a method
to determine the scanline size so use that instead.

Change-Id: Icccba8f26c5e0fd4bd4c37bba7c5a7fe8d0094bd

AccessReleaser does the same job as a ScopedBitmapAccess, but it
is a local class in pdf writer - removing it.

Change-Id: I3608a80fde8af938de479a9ecf44b134e1be7aa8

In impress there is (or was) a submenu "Mode" for images that
containted color transforms for images to various bitdepths and
palettes. The action is destructable - which means the original
is replaced by a new image. This also has little use today as I
don't think many people want to shrink image (byte) size this way.
The only useful transform is to 8-bit indexed for certain types
of images to save space without a bigger color degradation, but it
makes more sense to add this option to "compress image dialog".

Change-Id: I7450b2ec3507fb5d180cbd1ec879cb5560a2dd22

Change-Id: I8dd2624cf70dbb34f6fe0a1744c3266dcef07198

Change-Id: I97c7a1c3c8a1dca0227477b54c4ce17530bd6b33

...which doesn't inherit from cppu::OWeakObject in the first multiple-
inheritance slot

Change-Id: I1624e5c696d5a592f86e7c48849ecf3a39e1e6fb

Improved the isolation of windows headers.
Specifically, RGB macro is better handled now.

Change-Id: I0eeea16d0de9da3455810c80b0715f7b54ae8c3f
Reviewed-on: https://gerrit.libreoffice.org/20039Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

was generated a crash when running 'make check' on my Linux box.
These classes need to hold the SolarMutex when destructing their
SwClient base class.

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

Change-Id: Ic61b2b9a472431e5443c74eb8b319ff8796e1672

Change-Id: I56fb6eb96f0d7c0a80741ba1dec7a2cbe650c33c

Change-Id: Ic5aed60d40d0e1cd4c227032bc4cf9adbd7be00a

Change-Id: I07a8b2eaa11ca29e3303d323060c3a4c52823967

Change-Id: Id647a5b681e10defd944ccb2ec8509689df704af

Change-Id: I0b80042bdab33b52b339267292249add6f70ac3c

Change-Id: I682a6e4f1a9a5ca3047a4ba2a3229158a8229b4a

Remove export for all the netpbm formats.
Import still works but these filetypes don't preserve good quality
anyway.

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

Change-Id: Id586934c8ff635b1ec2b645b0956cc60960f6078

Unicode Notation toggle's alt-X conflicts with the main menu for Basque,
Galician, Dutch, and Brazilian Portugese.  Replaced with Alt-C which matches
the alternate combination already assigned for German.

If MSWord uses a different combination for these languages, someone can
request a matching change.  Dutch is confirmed as using the conflicting Alt-X,
but the other languages are unknown status in MSWord.

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

Although German (de) was remapped to use Alt-C instead, it still
assigned the en-US alt-X assignment as well, and accelerators
take precedence over menu ~ indicated keys.  So a blank assignment
needs to be made in the alt-X accelerator for any language that conflicts.

Added vietnamese as well - it conflicts with both alt-x and alt-c, so not
assigning any accelerator to it for now.  A vietnamese can request and suggest
an appropriate accelerator combination.

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

Set up the toolchain to create sources and javadocs artifacts in
addition to JARs created during the build. Use Buck build tool for
that: [1]. This is a fork of Google's build tool Blaze, created by
Xooglers at Facebook. This build tool (like Blaze itself) uses
Python to write build files.

Add needed tools and build files to install LibreOffice API artifacts
to local Maven repository or deploy them to Maven Central.

To build all needed artifacts LibreOffice must be built regularly
with GNU make first. To build the rest of the API (sources and
javadocs):

  $> buck build api

To replace version number with upcoming release version:

  $> solenv/bin/version.py 5.1.0

To install the API to local Maven repository:

  $> buck build api_install

To deploy the API to Maven Central:

  $> buck build api_deploy

Detailed documentation is added to document the prerequisites and
the workflow to upload LibreOffice API to Maven Central.

* [1] https://buckbuild.com

Change-Id: Ibdd552a01110836703bc069abe829b9921491cac
Reviewed-on: https://gerrit.libreoffice.org/20343Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I41b0ce2a024d7cc850fb7a380c992167fa004e72

Project: translations  0fec96207aa660bd7a5de1cd8694703c8d33e92c

update translations for 5.1.0 beta2

and force-fix erros using pocheck

Change-Id: I1b2faba1d02fc0d683d8d50c77fd8d0dba4c8abf

Change-Id: I0e2f269af47caa219bbf2a6a011febbea20791c2
Reviewed-on: https://gerrit.libreoffice.org/20339Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I9ab9c0eaf463c93caf116c98e47564562af0af5d

Removing an old hack that is no longer needed.

A table marked as “keep with next” doesn't split and keeps with the
following paragraph already.  It doesn't require this old hack to
function properly anymore.

Preventing tables from splitting had forced
large tables to always start on a new page.  Removing the hack
allows everything to lay out nicely now. There is a fairly large
suite of tests in the bug report that prove the proper layout of
various keep-with-next situations.

Any document depending on the old behaviour can simply  (and properly)
insert a manual page-break before the table in order to force it to start
on a new page.

Change-Id: Ie2036c1a638009aaf95247574998077a1e55b5e5
Reviewed-on: https://gerrit.libreoffice.org/20216Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>

Change-Id: I3d9ffbdd8246d7dee6b49393dd6875cab8565dc0

Change-Id: I5bdc1585be07357597c0527dc303643242f1d727

OOXML embedded objects are converted to ODF during export, which
prevents the export from working, as it expects a stream, and ODF
uses a storage.

There is already a unit test in testEmbeddedXlsx, but it wrongly
succeeds because the components necessary to convert from OOXML to ODF
are missing in the test environment.

Change-Id: Ib4df346e04ecfb54ec1a728535be876db921b884

Doesn't really change anything, but looks nicer.

Change-Id: I8f2dc41adaf22e11b1c15ba619ac00b6b72892fa

That's 197 more than the current release, surely a big improvement.

Change-Id: I48c81f9ae472a623ed9f59b94bb0bc921ad97c5c
Reviewed-on: https://gerrit.libreoffice.org/20303Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I6715b620adaa6f2b461cb900abb996b62d955ae5

Change-Id: I10d30097a7e7099d43a6760489dcbbf405828960
Reviewed-on: https://gerrit.libreoffice.org/20267Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I051e2682bdff3bf88fecd726bd57652e5f9e8806

When using appearing animations on shapes, some of the slide transitions
incorrectly don't show these shapes. Same for disappearing shapes - both
states are wrong during slide transition time. Fix slide bitmap
generator to take final slide states into account.

Change-Id: Iea0e576009a109c7f44a7a6498b0ee5b2c4791c5
Reviewed-on: https://gerrit.libreoffice.org/20199Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>

Change-Id: I9240cd2240940e03e895a7544c9f51a29b048355

Change-Id: I163f7d6c0f30ac2929df1cae202e695d21bb49fc

Change-Id: Icdbb361feea2ebee74f9d0a906bdd3c2882443e8

Change-Id: Ic4d3bcec7bda300bca6911a7472cafafdf12f5bd