Change-Id: Ida7914d7301c16ed1771be3d874c716c8fbaf8b4

Change-Id: Ie648ce55fdc11f907f5f5b3b958c13c695f392c5

I suppose it is the same misconception as in fdo#55931 - I am convinced that
the font metrics should not be used here.

Looks to me as if in the past, the font width computation was broken somewhere
deep inside OOo, and everyone instead of fixing the root cause was just
working that around by using the FontMetric; and then one day the root cause
was fixed, and all the workarounds broke ;-) - but that is just a theory.

Change-Id: I741bf8f4eaea4f7d8bc698dc9a8124109dfb8c20

it is fairly common when converting String to OUString
to find code that search for thing and replace/delete
these things... the later need OUStringBuffer, the former
OUString.
This add the search feature provided by the indexOf family
of function found in OUString, into OUStringBuffer

Change-Id: I2de818e6317a94ed520f338ebc9ed08d5f17765c

This is still not complete, but having the replacement graphic only is
far better than having nothing.

Change-Id: I141a3de1a449f4261c7086e10f2c141b3f6cdb10

LCMS2_CFLAGS must be non-empty for it to override pkg-config.

Use it in the cases where I yesterday changed SAL_DLLPUBLIC_EXPORT to
JNIEXPORT. It turns out that on Linux JNIEXPORT does not enforce
"default" visibility, but expands to empty.

Change-Id: I033b3cf538715fb596e965e17f3da12fb987df63

Change-Id: I376b03d12f8ae59fcf75046c42bcd6ba5d29af2c

Now with DISABLE_DYNLOADING, SAL_DLLPUBLIC_EXPORT actually means
hidden visibilty. Which is OK in general as with a single DSO (or a
single executable, for iOS), none of our "normal" entry points need to
be visible froom the outside.

So for the JNI entry points use JNIEXPORT. On "normal" platforms it
should be equivalent to SAL_DLLPUBLIC_EXPORT.

Change-Id: Iad634950e635ac03a0e90cae6d00afd9fb4eeb64

Change-Id: Iae8f93d096178532e2384a13b36e1385269aa14f

Change-Id: Ib766a4ed49d089488fc4ec67b941be2f38ba3ac3

Change-Id: I0261d30f20c88fc324194f687ebba3afd980117d

Change-Id: Ia3c103e4343d309b997ed37e33a382ffdfbddac3
Reviewed-on: https://gerrit.libreoffice.org/1014Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: Iedef29260ef10ecf9d5d95dfd87e1c5aaebfc3fb

Change-Id: I9f520ca7fb88c6843582595cd2d999d8060c9528

Corrected according to surrounding code. I don't know if or when
this code is called.

Change-Id: I4ed63439e47a89cc982d792c619c4c58335daf93
Signed-off-by: jailletc36 <christophe.jaillet@wanadoo.fr>
Reviewed-on: https://gerrit.libreoffice.org/1009Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: I34e1de922544e5e0f0ea0e03be5d238d600aa833
Signed-off-by: jailletc36 <christophe.jaillet@wanadoo.fr>
Reviewed-on: https://gerrit.libreoffice.org/1010Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: I36e57f8eac028e72fedd81a5fb05698ff1c57fe0

Change-Id: Ie2c55af903ef0fdf21444ee1f59d25382648d9fa

Change-Id: I10a524c49169611e2bf2e34988667e46474e17a8

Change-Id: I5d529cef6e75ccdfe57800bceace99353d4b4b47

Change-Id: Icc1e7f5be1a4c06242793948a07de20cf3e03b61

Change-Id: I1dfb345d3047b59c79454d60747d192a761071ef

Change-Id: I10433beb4c2cea508760083812bc63f4eab02ed0

Change-Id: I8359e1d441cf7bd8fb01233fe0303dbd6b35895b

Change-Id: I96de6b20b2a68f0982a30d33359e9e9cda9e642c

See fdo#56829 for what inspired this test case.

Change-Id: Iee15d85a35ae96769d21ce7061b352860a5b587b

Change-Id: I20045ae0ddcec228b153c4005855dca9c4ddbfca

check pre-decremented value for zero

Change-Id: Ib2289cb6064941db2072b2dfbd6ad5f03bcff7aa

Should be handled by lpsolve external

This reverts commit f66e86f3.

regression from f42a9309
which forgot to adapt getImplementationEnvironment to new prefix

Change-Id: If5a6f804b8f9f91e22f093a76f6b81a2b62991ab

At the point where std::unique is called, we can use order indices to
determine whether the two items are equal. This should be more stable
than using CaseInsEqual() to assess equality.

Change-Id: I88310fc7beede19fb1c629b9b7e3cb9a069b2b23

Note: This test passes just fine on master. On the 3-6 branch the test
itself also passes fine, *but* when re-creating the same scenario from
the UI, it fails only with the 3.6 build.  I have no idea why.

This test is modeled after fdo#54898.

Change-Id: I32eb9b2f2bdc12ef801daf0ccb9a3db2d5efd8d6

Change-Id: I8090ef9bbcbf335f742c2bb8843dd72a757ef048

Change-Id: I863ec02853042662accc2005fa1cd9340f950740

(PT Serif, Source Code Pro and Souce Sans Pro under OFL; Open Sans
under ALv2)

Change-Id: Ic783f0d5841cafce6dba60213b0a658978ff2cfd
Reviewed-on: https://gerrit.libreoffice.org/1007Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>

Change-Id: I3c6f160b7d19531df317d39723d1633ce58cccf9

Change-Id: I3354f1c6b1eb5b1a78c25ff6ac23218336fd8bea

Change-Id: Ic7edfe9c919cc2c0e3cd8b68d130919c4054686c