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

Change-Id: I7bfdb02a97d6a33c0a6e16b058cbb10b8ab2869b

Change-Id: Ie6183a7e78b671a2d126127e4fcaa3b353d8a324

Change-Id: Ibd8e68a5a2ebd6ac2a829004c8918f9a449ef5d7

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

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

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

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

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

As requested from Michael Stahl here:
https://gerrit.libreoffice.org/#/c/12164/

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

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

This patch resolves the problem that Basic fonts(Asian) are Arial
Unicode MS in Japanese locale on Mac OSX.
Expected behavior is that Basic fonts(Asian) are Hiragino Mincho ProN
font.

LibreOffice 4.1 and later, on Mac OS X, the font family names are kept
without suffix(e.g. w3, w6) in the system font list.
Some font names in VCL.xcu (font family name including the weight
as suffix) doesn't match the font name kept in the system font list.

This problem reproduces at the CJK fonts environment.
This patch resolves this problem with Japanese fonts environment only.

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

Change-Id: I4b2bedb9ac641fcb96d09afb2e60fa2c6186fd6b

To make the conversion in the TabDialog ctor unnecessary. Put
conversions to other subclasses till they are properly adapted.

Change-Id: I6152b6229ce9c840262739cf11812538c9e0a532