Player can only update the duration when the state of the
GStreamer pipeline changes. But GStreamer need some time to get
ready. However the default duration (0.01s) is so short that
the audio node is deactivated before the duration update.
Hence I just pick up a value that is long enough to allow
update happen empirically.

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

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

Change-Id: I65d16c3561fa6fd83aa37cb12ae4fd931d03029f

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

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

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

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

aVerticalLeftToRightBottomToTop was wrong, it mapped from physical to
logical, and it should be the other way around.

In practice this means that when SwTextFrame::AdjustFrame() is invoked
for a second lower, then nAdd will be a small positive (and not a large
negative) number, so the

warn:legacy.osl:20827:20827:sw/source/core/text/frmform.cxx:479: Ey

warning goes away and the second lower becomes visible.

Change-Id: I894fef4a89b1feeb333537ff7d76793130007ed8
Reviewed-on: https://gerrit.libreoffice.org/67862Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

Use range-based loop or replace with STL functions

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

Change-Id: Ic7c6c648c71203116ca074bd7392a48ff850cd51
Reviewed-on: https://gerrit.libreoffice.org/67864Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>

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

Change-Id: I9d85f6a86d96353312bb00aeb1c173fa9fdfefda

Forgot to remove in e756b6f3

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

* Update helpcontent2 from branch 'master'
  - tdf#121532 Don't use non-standard `echo -n`
    
    At least the version of echo used to build TDF's LO 6.2.0.3 release apparently
    doesn't understand that non-standard option and printed out "-n" verbatim,
    generating a broken languages.js.  (Though my local macOS 10.14.3 /bin/echo does
    understand that option.)
    
    Change-Id: I7233fa5c6e7851c5086c428a67aaee71604061e1
    Reviewed-on: https://gerrit.libreoffice.org/67858
    Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
    

Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.

Change-Id: I819bb44e36bdb6ec671cf11bd779085767d82fd0
Reviewed-on: https://gerrit.libreoffice.org/67697
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

This ensures that no extra slashes are added to the path when it
already ends with a slash; for Windows drive root path (e.g. C:\)
the trailing slash is always kept to not change the meaning to
"current path on the drive", which is different from "root of the
drive". Our IsValidFilePath does not allow more than one slash
after <drive:>.

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

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

Change-Id: Iedda7ca9cff1bda763845e665e0e21656b253793

In particular, the value 2 means "do not save".

Change-Id: I9788d201f8ecfcc016a12aa2088552ee994e1c17

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

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

Till it's clear why it has unexpected values.

Report from mailing list:

> Test name: SwLayoutWriter::testBtlrCell
> equality assertion failed
> - Expected: 2707
> - Actual  : 2710
> - In <>, attribute 'y' of '//textarray[1]' incorrect value.

Change-Id: Ic914f513df544dcf472b0870a3936f87d876c76b
Reviewed-on: https://gerrit.libreoffice.org/67856Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins

Change-Id: I831321bcce241bc180e22b20364137f776fee0f9
Reviewed-on: https://gerrit.libreoffice.org/67847
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

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

It has nearly correct formatting already, lets keep that.

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

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

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

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

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

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

Export the shapeProps (fillstyle, linestyle, linewidth,
linecolor etc.) of the Error Bars to OOXML.

Change-Id: Iff74fa463fdd0fb6ed95e4d1bf0d3e906349860c
Reviewed-on: https://gerrit.libreoffice.org/67825
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>

It passed "make check" on Linux

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

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

we want to know what it would format as, but we don't want to do
the formatting during typing

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

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

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

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

The problem was that the x position of the btlr text had a 159 twips
difference (it was too close to the cell border), since the text portion
height -> baseline offset calculation worked with the descent, not with
the ascent.

The position of the text now matches exactly what Word does.

As a side-effect this means that multiple portions in a line and also
multiple lines in a text frame now work correctly.

Change-Id: Ic139db328e2a913e5cae4026886c3410cdab357d
Reviewed-on: https://gerrit.libreoffice.org/67823
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>

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

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