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
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
4d6dab2cde and then later committed a patch that
removed the ability to use the environment variable USE_XOPENIM as it wasn't
necessary anymore (commit: 8b0287543d). 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/12473
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
Tested-by: Chris Sherlock <chris.sherlock79@gmail.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
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/12467
Reviewed-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Tested-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
