Change-Id: I8b3d1f7af217d36a9baf62df3e62f1361b8c57bb

Change-Id: I4b7829a1abe1459f2e4915159588fd3e16a14eea

Change-Id: I8006aaa4474f086ce5381f59afcf7a5f15279b55

Change-Id: I07a822a7c03a4746fd609ca6ea743b92253cf6de

Change-Id: Idd6c9f9752659fc5da575e5a3f0ffc15ce5dbe1c

Change-Id: Ie368fecd39189dc6ea72737b0c695c55a2d350a9

Change-Id: I5348977de17d3f916cecabe4b5c3f7630a89667e

Change-Id: Ifb29bd3e9c5dc7671c189fd9daa010305f7a85a4

Change-Id: I86d9f131ed48067984cee3fce13d48c82e7f4775

Change-Id: Icfbbae898749196e27199802ec728417d5205bc5

Change-Id: I55ea4ca2774433b204d2b0197e720ece4b0dadab

Change-Id: I4eec581ad83c8aceea8e853d2d19275f77029a68

Change-Id: I3e2738210b2fb598e15528e262f76a3ec140ab18

Change-Id: Icba402cecdc4997e95250544a887b9ed3399f197

Change-Id: I474006e128788336680e28c9f73d4a26e68541c6

Change-Id: Ifed65f41ab2375d702bf0c4299c65d1e3d78a7f0

Change-Id: I615ee0ec9aca3c30018fb45f91240471b88e96eb

pleasing cleanup of whacky ScRawToken::sbyteOffset, etc.

Change-Id: I5ad97f8dab7c5dc9d5f0286bf606b619126c22c9

Currently rtftok doesn't handle multibyte string as destination
text very well. For example, RTF files created by MSO 2010 Traditional
Chinese version use CP950 (aka BIG5) for unicode to ansi conversion.
When a Chinsese numbered list was picked, the Chinese dot ( unicode
0x3001, big5 0xa142 ), was used by default as a list number suffix.
However when it is imported , only a single B (0x42) were left.
The theory of the patch is to collect both hex string and normal
character with m_aHexBuffer, and convert it into OUString as late
as possible. It allows prefixes and suffixes to be imported from
RTF files created by MSO 2010 TC correctly.

Reviewed on:
	https://gerrit.libreoffice.org/12435

Conflicts:
	sw/qa/extras/rtfimport/rtfimport.cxx

Change-Id: I63062da39bf36ea27ec11e5d0eb1d1abf5018d96

Change-Id: I484331c4dd5feedf8587530912bb65556c1689c0

Change-Id: I839435338f4acf80c40896b6c86f7ef122f5449d

Change-Id: I7408be90f1ff552f4bb33e8a89d4b9075634e3e5

Change-Id: I4f5f0f653f2ce7782ec1d1fc5ef550a21a9c1d35

Change-Id: Iae88a9889c674337fb999a23a799d8730d2793d5

Change-Id: I8cd2ce341996a219ee885969de3482be422730b3

Change-Id: Iac813b78c476b69dc6aa78d48c025f5fda76db1a

Change-Id: Ibbec7a5d9b6726865da14c9bdfad8b8118f85e5b

Basically, they were working around issues with XmbTextListToTextProperty
returning garbage characters, which showed on window titles.

The comment in the code is far more informative than the bug report:

 /* #i64273# there are some weird cases when using IIIMP on Solaris
    where for unknown reasons XmbTextListToTextProperty results in
    garbage. Test one string once to ensure safety.

    FIXME: This must be a bug in xiiimp.so.2 somewhere. However
    it was not possible to recreate this in a small sample program.
    This reeks of memory corruption somehow.
 */

Now I did a bit of research (aka "Google search") and discovered #i6759#
which was logged in 2002. This shows that the codebase was using __XOpenIM
in xiimp.so.2, which probably caused this issue. From the bug:

    I've tried to look into this problem and have found out, that
    apparently the
    use of the '__XOpenIM' subroutine from the
    /usr/openwin/lib/locale/common/xiiimp.so.2
    shared library causes this problem.  When running on Solaris, OO tries to
    dlopen() the above mentioned shared library, looks up the  '__XOpenIM'
    symbol in it and calls this function ( function XvaOpenIM() in file
    vcl/unx/source/app/i18n_wrp.cxx ).

    There's alternate code in OO that just calls the X11 documented function
    'XOpenIM()' instead.  This is enabled by running OO 1.0.x with the
    environment variable USE_XOPENIM defined to some value.  When running
    OO with

      env USE_XOPENIM=1 ~/OpenOffice.org1.0.1/soffice

    the problem does *not* occur any more and xprop for the same two windows
    mentioned in the initial bug report shows:

    % xprop |egrep '_NAME|_LOCALE'
    WM_LOCALE_NAME(STRING) = "de_DE..ISO8859-15"
    WM_ICON_NAME(STRING) = "unbenannt1 - OpenOffice.org 1.0.1 "
    WM_NAME(STRING) = "unbenannt1 - OpenOffice.org 1.0.1 "

    % xprop | egrep '_NAME|_LOCALE'
    WM_LOCALE_NAME(STRING) = "de_DE..ISO8859-15"
    WM_ICON_NAME(STRING) = "Umbruch einfÿ77777774gen"
    WM_NAME(STRING) = "Umbruch einfÿ77777774gen"

    As far as I can tell, the use of '__XOpenIM' frees some memory inside the
    Solaris X11 shared library that is still in use by the X11 character set
    conversion routines. Or in other words: the X11 character set conversion
    routines operate on freed memory, after __XOpenIM was called.

    These character set conversion routines are used by
    XmbTextListToTextProperty
    ( in WMAdaptor::setWMName() in file vcl/unx/source/app/wmadaptor.cxx ) and
    it seems they still access memory that was freed by the use of
    '__XOpenIM'.

Now later on, Caolan removed XvaOpenIM() in commit
4d6dab2c and then later committed a patch that
removed the ability to use the environment variable USE_XOPENIM as it wasn't
necessary anymore (commit: 8b028754). I'd say
that this was probably fixed in one of these changes.

Change-Id: I20effd77e0cdcde26d1be756cc6231f30f35118e

There's never a case where we need to get the width from VirtualDevice,
we really should only get it from the SalGraphics instance. This vastly
simplifies matters.

Change-Id: I8bae9c163fcb0ce5d064d802c2783437124ebcb2
Reviewed-on: https://gerrit.libreoffice.org/12473Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.com>

Added locale text to About dialog

Change-Id: Ic26219e8fe845b4c5027b65d5f5edba9279b1b11
Reviewed-on: https://gerrit.libreoffice.org/12464Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>

Whether this stuff actually works at all for iOS any more I have no
idea, and can't be bothered to check in my own time. Why do I bother
fixing compilation errors then? Good question.

Change-Id: If0ec4fbde42536d3d90e8c5337948815b5f47cef

Change-Id: I57cfac2993301e438124c224655fdcac0ed0fd32

Change-Id: Ie44a743a6814cdf1bc15f850547ae71afd595836

If a forward declaration does the job, use that.  Adding a new header
in document.hxx is a very expensive operation since almost everyone in sc
includes document.hxx.

Change-Id: I2d78440d65da7207ceb16cb28a7404249eba066a

We can remove these colors from the UI because these colors are equal to
cyan and magenta, and will be useful just in the import/exports filters. If the
user still wants to use aqua and fuchsia, they can type them in the Math editor.

Change-Id: Ia93d458e07b218aa007ec43bd490f774e5b4ea5b
Reviewed-on: https://gerrit.libreoffice.org/12467Reviewed-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Tested-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>

Change-Id: I74a671656a703eefa9ae10e839c156a4c0f66335

Change-Id: I06525aa32bc17464291126ed676809e23e4227b1

Change-Id: I51fb7cb025f4dc2bb7f3bf0ba5c9b8ee90298cd8

Change-Id: I8169e9ceefc48c06b358d5a8e1fc08dabf019eb3

Change-Id: I0c7c28ef77676f8bcb6cf66423d30e3ea164a5bc