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

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

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

I know Solaris is a snowflake, but it is 2016 already and I think it can
handle FontConfig such fine.

As for the undocumented envvar, lets pretend it never existed because
that is what undocumented feature are. Anyway, it was introduced for
https://bz.apache.org/ooo/show_bug.cgi?id=85483 which is long obsolete
already.

Change-Id: Ib50f129a3828ed2ee5167178c6ff2467d2c8d96c
Reviewed-on: https://gerrit.libreoffice.org/31517Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

Change-Id: I285dab1e18d3455ae97080982832e29a97e5acea
Reviewed-on: https://gerrit.libreoffice.org/31513Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

On my system reading the ~400 fonts I have takes ~0.07 seconds, which
does not really justify all this complexity. We don’t have such cache on
other platforms as well.

It might have been slower in the past with all PFB and AFM parsing, but
this is gone already.

Killing this ugly fontmanager over engineering one piece at a time.

Change-Id: I41fe3db48dc3de0cf8939c2120403f7d243d6096
Reviewed-on: https://gerrit.libreoffice.org/31511Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

Change-Id: Ief5121967b12692c60a4b462617d91786e901b9e
Reviewed-on: https://gerrit.libreoffice.org/31504Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: I6af48e37b1b796a1680447ff972de8b5f5623d26

The problem here is that when switching to the print preview, there are
2 view shells, SwEditShell::UpdateTable() is called and the first one
does some layouting in ImplEndAction(); this creates a11y events for the
2nd print preview one (see loops in SwViewShellImp::Invalidate*) and
stores them in the SwAccessibleMap since there is an Action going on;
then SwViewShell::ImplEndAction() for the print preview shell is called
but it returns early without sending out the events, so they remain
until the ~SwAccessibleMap asserts about them.

Change-Id: Ie1c6b82fc5f2cdb2998d514a632295ad07e97517

Change-Id: I8fc4d849e434e245d871dc2d2eef42713e1359bb

Change-Id: Ic340d7226ea3af4bbd6e52c415b32d9be7cd453f

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

Found when attempting an enum conversion.

Not sure what effect this will have, it was introduced with

    commit a0c7b2bc
    Author: Oliver Bolte <obo@openoffice.org>
    Date:   Tue Nov 16 10:24:21 2004 +0000
    INTEGRATION: CWS eforms2 (1.48.52); FILE MERGED

which pushed a whole bunch of stuff together.

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

Change-Id: I1b23db2335827cab6f1b98b40103b0508928b66e

e.g. fdo35235-1.odp

Change-Id: I259cdc9ed073be2ad7d5208cd943d4f193f09c16

Happened when the doc was smaller than 1024 bytes.

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

From a comment's point of view, EOF is just a terminator, similar to \r
or \n.

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

Also fix parsing '<< /Foo [ /Bar ] >>'.

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

Map it to the partially signed (not all streams) ODF concept instead.

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

Change-Id: Idfc964930c242d752a78cd109d75d809bce4de11
Reviewed-on: https://gerrit.libreoffice.org/31470Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

The existing osl::Condition is an API and reliability disaster area.

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

See https://msdn.microsoft.com/en-us/library/dd921584

Change-Id: I66c9474cbf83cea10ab0e7c2b44592673c8b683f
Reviewed-on: https://gerrit.libreoffice.org/31456Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

Change-Id: Ia9458f8ac32bb8c6da6fc08e5fee527ca6fb8bd5
Reviewed-on: https://gerrit.libreoffice.org/31473Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>

Change-Id: I574c3f719e52bc2244597532783130564621a891
Reviewed-on: https://gerrit.libreoffice.org/31303Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

With Fedora 25 GCC 6.2.1 and my usual config (except without
--with-package-format since that is slowest now) on commit
086631af i get with CCACHE_DISABLE=1:

With -O0:

"make check"
44490.70user 3127.01system 1:15:23elapsed 1052%CPU (0avgtext+0avgdata 2541312maxresident)k

"make check", incremental
7368.19user 153.98system 15:30.06elapsed 808%CPU (0avgtext+0avgdata 510200maxresident)k

"make CppunitTest_sc_functions_test"
272.13user 0.65system 4:33.47elapsed 99%CPU (0avgtext+0avgdata 258884maxresident)k

With -Og:

"make check"
46076.01user 3170.91system 1:16:19elapsed 1075%CPU (0avgtext+0avgdata 2613716maxresident)k

"make check", incremental
5478.33user 157.07system 11:50.42elapsed 793%CPU (0avgtext+0avgdata 454980maxresident)k

"make CppunitTest_sc_functions_test"
188.48user 0.62system 3:09.59elapsed 99%CPU (0avgtext+0avgdata 259096maxresident)k

So we now have so many tests that the time taken by GCC doing optimization
is brought back via the tests finishing faster, particularly if we
assume a non-negligible ccache hit rate for developers in practice.

Add this to gb_DEBUG_CFLAGS instead of gb_COMPILERNOOPTFLAGS because
presumably the bridges code that uses gb_COMPILERNOOPTFLAGS really wants
-O0; the gb_DEBUG_CFLAGS is added later so -Og overrides -O0.

It is an open question how well debugging in gdb actually works with
-Og, some experimentation is needed; "man gcc" claims:

       If you are not using some other optimization option, consider using -Og
       with -g.  With no -O option at all, some compiler passes that collect
       information useful for debugging do not run at all, so that -Og may
       result in a better debugging experience.

Change-Id: I103499f398b69397cf5aa9993a242680966ce999
Reviewed-on: https://gerrit.libreoffice.org/31334Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

gcc-4.8 introduced a new optimization level -Og which enables
optimizations that do not interfere with debugging.

When configured with --enable-debug, use -Og rather than -O0
if available.

Change-Id: Iff3f98d736681ae34e49b96510228a14ce456b34
Reviewed-on: https://gerrit.libreoffice.org/31333Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

This caused not finding the length of a stream -> could not actually
verify signature.

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

Change-Id: Ic72fb18eccb54b24f4205d997585cee753965b10

And replace gb_AllLangResTarget_ALLTARGETS with
gb_AllLangResTarget_REGISTERED which should have
the same content and is already used.

This actually helped to find a problem, fixed in
52d409f0

Change-Id: Iae551d7be221c5655dee1bc9ad273c8822d45178

Change-Id: Ia8a1207a584b599f01c47b658692d3eeae52cb3a

Change-Id: Ib6aecbcc993f2b8898a2c9855181d3b7db1f9840
Reviewed-on: https://gerrit.libreoffice.org/31444Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>

If we skip to the first NL, then we start tokenizing some XML as PDF
data and soon error out due to an unexpected keyword.

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

This is broken, but work it around to avoid an infinite loop.

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

Assume T0 calls ThreadPool::pushTask twice, then ThreadPool::waitUntilDone:

T0 calls ThreadTaskTag::onTaskPushed:
  mnTasksWorking = 1, maTasksComplete.reset

T1 runs the 1st task to completion and calls ThreadTaskTag::onTaskWorkerDone:
  mnTasksWorking = 0; suspended...

T0 calls ThreadTaskTag::onTaskPushed:
  mnTaskWorking = 1, maTasksComplete.reset

T1 continues in the call to ThreadTaskTag::onTaskWorkerDone:
  ..., maTasksComplete.set

T0 calls ThreadTaskTag::waitUntilDone and immediately returns

T2 only now starts to run the 2nd task

Change-Id: Ic29101a4791fca2a1a4d54b559f10ff706e8a20d

Change-Id: I498bb634f2a5800f5effab99227aa4699ed91aae

...seen JunitTest_sc_unoapi_4 fail once in
sc.ScHeaderFooterTextCursor::com::sun::star::text::XTextRange with an empty
RuntimeException when calling some remote getString.

Change-Id: Id631feffce810b40825fe0fa49d8f1846f045033

And a couple of other changes to accept the bugdoc from
<https://github.com/esig/dss/
dss-pades/target/test-classes/plugtest/esig2014/ESIG-PAdES/RO/Signature-P-RO-4.pdf>.

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

Going via UNO for a class in the same module is an overkill.

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

Change-Id: I33f8322a6371150698bf926165fb6dddb9d4092c
Reviewed-on: https://gerrit.libreoffice.org/31452Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>

Change-Id: Ic960da6a479523a9255357d5f4cede212ff9c6a2
Reviewed-on: https://gerrit.libreoffice.org/30404Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>