Change-Id: Ic4b74d769ee4370c5182c9921483c7ec0b2c7a94

This way should cover all un*x-like OSes (unopkg.sh excludes
e.g. OS X)
This effectively reverts commits 723e0999 and
9444ffc9

Change-Id: I0b4425d1c9eff8e51e5d9a4dab35775084106a23
(cherry picked from commit faa2c06226146e3ab4b7fa8096cf213ea9d52a23)

Change-Id: Ife8c272d2ac110c44908b0e248f0c53c0f477c06

Change-Id: Ifc63714b6b9e797b668cccc46052cb9d791122ea

The compiler's __GNUC__ etc. need not match the libstdc++ version used (esp.
when using Clang as compiler), and libstdc++'s __GLIBCXX__ macro doesn't inrease
monotonically with version numbers, so resort to a configure check.

Change-Id: I06de6b68324169863f6f5c31ae5d855e8b04cd6b

Seen with gtk3-3.10.9.

Change-Id: I0fc3f6187e270bb13d110bee7c817b5f48d4ce50

SdXImpressDocument didn't have this problem, FWIW.

Change-Id: Ic88311596b7b92a8e972f366b9e82cca850244f8

because the gtk3 fpicker puts them in the new header bar
are now

Change-Id: I78334476b42366ffdc64da9460eb017c8bc61622

This reverts commit 26dacbb13d7d40b5ed2bf934dbf94b35919d0562.

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

Change-Id: I406977acab12a2f805de1f57b91378e9b80195d4

its clearly accidental to do this only for gtk3, left over from various
screen/xinerama untangling efforts

Change-Id: Ic91f41fad5748f68fbefca1d6798fef6e2efe469

Change-Id: I3fbbd0f3b42a3be1c2a9c54eb8f35dd18f550b16

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

Change-Id: Ie96ccd3b3b0e2bebf10496f91d110d9a1a62e133

...with numeric values that are not meant to be characters.  Inspired by
<https://gerrit.libreoffice.org/#/c/16339/> "OUString: add constructor from
single Unicode code point" and ecaf1cb3 "seems
to be what was meant."  Found e46e8d19 "Shall
this produce a string representation of a number?" and
f2a0e403 "Don't truncate a UTF-32 code point to
a UTF-16 code unit."

(LIBO_INTERNAL_ONLY mostly because it uses a C++11 delegating ctor for
simplicity, but also because it requires mild modifications to client code, see
additional changes in this commit and some other recent commits.)

Change-Id: I8a156f01d1b772c6052d7afaa088ae13ed234e2b

This reverts commit 30e87214.
which I accidentally pushed.

workaround GCC4.8 issue

Change-Id: Iea4d10a02a114ce94e0219e8b89acf48db5411d0

the benefit here is that we avoid setting bObjOrdNumsDirty to true,
because we almost always need the ord number the very next time this is
called.

Change-Id: I0b974b79e69754d35095e197400584df4a89bfe9

Change-Id: Iaa1164904febd8e97d4962e4004ec4719a1f4a42

Set the UILocale to en but do that with a registrymodifications.xcu as
setting it via configmgr requires a restart.

Change-Id: I26d9f6aa07852a7f18e2b3b7baccdb2e85524ea4

Change-Id: Ic889efaca00ad9600b1b5c8452aa7ee819e63c89

Change-Id: Ibf2184f565225423f57597fe96164565b5a3194a

No need to introduce a special env. var for this I hope.

Change-Id: I700299c4f40d504a4a437e9bb73f5b24856f9bf8

Change-Id: Ibc9e93c702e885b14d7c0beac453479e9171f329

Change-Id: Iee0c33cba80243b39b6de96cf58b8b274346e522

Change-Id: Ic6a373fd3d809f7fc8b3d7f724be7a56383f3fa8

after my commit e0f3e7c0
"tdf#42374 some small optimisations for opening this PDF file"

Change-Id: I908770ca618581ffe26ebb2205b804d1abcae5a7

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

(like 8313f683)

Change-Id: Id170cc95f5271d3e5c3fa84dafd848e7f8a96503

Change-Id: I769cc6e11909c7f4c6394fdc4dec8a12b9a67af8

Change-Id: Ibec141be604f15d1c6358d3365a7a3e60c135f1f

...instead of assembling a OUString and calling OUString::hashCode.  It appears
that these hash values are only used in std::unordered_map instantiations, not
used as part of a stable file format.

Change-Id: Ie3f78b2cc9e162ac9777c7e5f4164a12bc9a62a4

(One difference is that for an XFListLevelBullet for which SetBulletChar has not
been called, ToXml will use an empty string now instead of a string containing a
single NUL character.  But given that initializing m_chBullet to zero in the
XFListLevelBullet ctor was only added recently with
72069675 "coverity#738770: Unitialized scalar
field," assume that ToXml is supposed to be only called after SetBulletChar has
been called.)

Change-Id: I7a5d7496b038cd094ab11ef8cbc1823ffc5bc130

Change-Id: I951e95c4c81e7e0b4bfb2246c163809863fedac5

Change-Id: Ie332b3d088547f6bcc676471182420766ecfedca

Change-Id: Ie12370fbd0b1d5aaacd56d6e21de29b6134d9741

Change-Id: I057c2d346be6a6775f01a3a32edd4fc8224271a5

On the one hand, the code had apparently treated nIdx as a sal_Unicode character
value ever since its inception in e7189508 "new
querydesign."  On the other hand, the preceding BROW_VIS_ROW case does produce
strings "0" and "1".

Change-Id: Ife6e98ba32146cc469b722fa4f013c12152b5505

...on a string potentially of length > 1

Change-Id: Ibdb8c3bb6e1630883069ff7dd17161014548ee76

Change-Id: I505400d539c36744a5ac138e63346a2a38f07b51