Some transition, such as those involving clipping, is not displayed when
switching from last to first slide. That is due to the fact that the
leaving slide (the last one) is over the entering slide (the first one).

The issue has been solved by hiding the last slide and placing a view to
it (svg:use) behind the first slide.

The text decoration unit test has been modified.

Change-Id: Iac1d23a1b9834c301b8ae511ea3f81397e5a4229
Reviewed-on: https://gerrit.libreoffice.org/20705Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>

Change-Id: Ib5e303599b04b031d7eefed56603bce0d1e1e570
Reviewed-on: https://gerrit.libreoffice.org/20650Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>

Change-Id: I81223b868f069755e8a46c57bfe0282021f26de7

Change-Id: I93b7298d785e57a4ef854cea3e9cd5c2c0f35849

Change-Id: I83c0febcbbf0f19a05818e0575921d1d6254935f

Change-Id: I52e6d6c9cb48880185293fb9825d7a6530ee767d

Change-Id: Ib534e4e8ecf50a9159c5e98e2c899bf13f44c654

Change-Id: Ia303a5dc97fb5e491e86a3484040e657f1b480d4

Change-Id: Ibcf05263f7bea50f70d55f4d8944d0a41d54851d

Change-Id: I0b4ee14ea2306786351ce20960a05e8f3058fb21

Bullet of non-monospace font that is used as non-printing character
to indicate space might be wider than the space. Drawing the bullet
over the space make the bullet too close to next character.
Shift the bullet accordingly so that bullet is centered with
original space.

Change-Id: I0d8d721041e8a475546fe25fb01bee374fc3e499
Reviewed-on: https://gerrit.libreoffice.org/20112Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mark Hung <marklh9@gmail.com>

Change-Id: Ie80a8e8132214164a4a237b0e5ea89c1b41d8ee3

A few icons are still left in the folder as these are used as fallback for tango.
See industrial/README for details.

Change-Id: Iaeb672609cd57bba5707cbafbfe295bfb8c5011d
Reviewed-on: https://gerrit.libreoffice.org/19149Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>

Change-Id: Iafe0c422f8681bd2ed5b825af180facb59aaf531

And fix some const-incorrect-ness while at it.

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

Change-Id: I79facae1159f878092a47560bb1c4488842fcc0a
Reviewed-on: https://gerrit.libreoffice.org/20811Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>

Change-Id: Ib49f52c94ae96b8bddec6718585d5d7d6e3d148d
Reviewed-on: https://gerrit.libreoffice.org/20806Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>
Tested-by: Kohei Yoshida <libreoffice@kohei.us>

Change-Id: I276f7bbf2bd6fa7c67d8691634ad9d79e4a08b1c

Change-Id: Ie0c819ac3f8b0c0b165e95ae5e58405a12c38472
Reviewed-on: https://gerrit.libreoffice.org/20753Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

This avoids problems with the initial default context getting destroyed.

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

Flipping of images was not working if it was only horizontal or vertical,
if both options were selected flipping was treated as a 180º rotation
and that make it work. Problem only affected png files because this
kind of files are treated different from jpg's.

Change-Id: Ia0e4a2b16a714cce0b7fb00d6f0a25fb3552d3b8
Reviewed-on: https://gerrit.libreoffice.org/20782Reviewed-by: Jacobo Aragunde Pérez <jaragunde@igalia.com>
Tested-by: Jacobo Aragunde Pérez <jaragunde@igalia.com>

with --headless --convert-to pdf ooo93489-1.ods

probable regression from...

commit d4daad18
Author: Jan Holesovsky <kendy@collabora.com>
Date:   Mon Nov 30 10:28:43 2015 +0100

    sc interpreter: Move the code that can create a ScFullMatrix.

In that original code I see there was a check for "Data array is shorter than
the row size of the reference. Truncate it to the data" which doesn't exist
anymore. If I reintroduce that check here the crash is avoided.

Change-Id: I7c7a5979d9c14c133b05e89ce3794e6b739ca61c
Reviewed-on: https://gerrit.libreoffice.org/20794Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Project: help  78c7e1c24aacacfa69c8de3644b154e98d858f7e

Typo: doubled period

Change-Id: Ic41033ee91fa10ba5b9d4ec84f7a7a006b944095

Change-Id: Ic974159f816bae465339e1b9abd2e247bbc2f206

Change-Id: Id4e9fefc3529a8e1b0079b47ff182ef54e19a0e8

Change-Id: Ia9d061d9f5fb07e07fd6253a6493a4e9b1f9c975

Change-Id: I5abc1d6fae7186342e45a83253d56c2311ec5139

Change-Id: Iaaf8e5f14691cde32058a78842b9c411f2b92d93

even if column is not nullable

Change-Id: I72ceda68e983125aef26c8f0aacc06320bd16b77

Change-Id: I6f9222dd40c553e1d0ad63e00e5874be939a97c1

Change-Id: If5ede0c308930d37bff9e97afc8a76cc5b709034

Change-Id: Id4aac707666420752b985bcfd03b5b9bb99f79f1

Change-Id: Id8f0c138fb665a19b92f2779aa59ae1778efddc5
Reviewed-on: https://gerrit.libreoffice.org/20789Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Oliver Specht <oliver.specht@cib.de>

... and way less overhead, geez..

Change-Id: Id9277301fbe69bc9a83ca39a907032b0b86b1c81

In case of empty values , the accelerator character is passed as the button name which avoids extra spacing.

Change-Id: I8a82f5226e17bf8977fb6a8fd59c99a244e59309
Reviewed-on: https://gerrit.libreoffice.org/14498Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>

Change-Id: I9e9c78387627e173dea8062e4a3f16bc396e8115
Reviewed-on: https://gerrit.libreoffice.org/20720Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>

Change-Id: Icd3cf90bf617c9c77dcf9cbda705bf348f980fb3

The problem apparently was that the GraphiteWinLayout::DrawTextImpl()
function drew each glyph using a separate call to ExtTextOutW().  That
mishandled anti-aliased glyphs (alpha), somewhat in the way as
described in the nice long comment (thanks kendy!) in
WinLayout::DrawText().

The irony here is that in the case of Graphite fonts and OpenGL, it is
exactly from that code block in WinLayout::DrawText() that
GraphiteWinLayout::DrawTextImpl() gets called, and in that situation
it itself runs into the same or similar problem as the calling code
wants to avoid for the run as a whole. It draws each glyph separately,
and subsequent glyphs will overwrite the rightmost pixels of the
earlier one instead of blend properly. Or something like that.

As a solution, change the interface of DrawTextImpl() so that instead
of being called once to draw a run of text, it might draw just a part
of the run, and in that case expects to be called repeatedly to draw
the whole text.

The GraphiteWinLayout::DrawTextImpl() implementation does it like this
in the case of using OpenGL (as indicated by the presence of a
non-null pRectToErase, as added in
b7842c93 for tdf#95648). The end
result is that it draws one glyph at a time into the DC for the bitmap
allocated in the caller, WinLayout::DrawText(). The caller uses that
bitmap as a texture and blends it into the actual destination,
separately for each glyph.

For non-Graphite fonts, or when not using OpenGL, nothing should
change. No repeated DrawTextImpl calls are done to iterate over a run.

Change-Id: Ib7adc30665fc7804913fd2f8886c5b29d9ca42c4

Change-Id: I527eeb82202de0d7b3545c545c492eda89c78e47

Avoid creating our own OpenGLContext to render until we need to
refresh the screen.

Change-Id: I29d4a1cb6193c92ed77ae98566f8b897a6bc67b5
Reviewed-on: https://gerrit.libreoffice.org/20709Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>