When editing shape text, the text selection should be provided by
editeng.

Change-Id: I379f89fc28d2ff8172d0411bba347c959de6ab29

Change-Id: Ibfa971952cd330ddf430e7e951c5c235d2ae6bd8
Reviewed-on: https://gerrit.libreoffice.org/16314Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I0f8de2b856be65e070f9d9b121515aa15ae3ea09

Change-Id: Ia7b784d820249c3d75915761dac34a2aaa190c0b
Reviewed-on: https://gerrit.libreoffice.org/16358Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>

In 'g' shell script, we use grep to get substring from config_host.mk file.
When config_host.mk file contains non-ascii characters(e.g. Japanese),
this processing doesn't work.
As a result, some variables(SUBMODULES_CONFIGURED, REFERENCED_GIT, LINKED_GIT) will be
assigned to "Binary file (standard input) matches".
This is an error message of grep.
The problem will reproduce on Cygwin64 with Japanese locale.

With '-a' option, grep will work well, and 'g' shell script will work correctly.

Please refer the following commit,too.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=0293ec98c92fd58a592f7dd86fbbf47e7b9195c6

Change-Id: If4e0b356173c8f442e3539ed343f441d87dbfd48
Reviewed-on: https://gerrit.libreoffice.org/16344Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>

Change-Id: I733dd57e27330bc200f718ffb5680bbb81d5d77d

Change-Id: I3f09808e43d379f473360f3746302a5d65fb8b38

doesn't work yet, but reports correctly what external formats
are available

Change-Id: I11cf9440ca516d4358c341fa67cc836b30ca42d6

The text is badly centered. Replaced GetTextHeight by GetTextBoundRect
and updated computation of text bounds.

Change-Id: I1e177a15787c6eddf2878a7d0254f71f3501ec34
Reviewed-on: https://gerrit.libreoffice.org/16354Reviewed-by: Philippe Jung <phil.jung@free.fr>
Tested-by: Philippe Jung <phil.jung@free.fr>

Let's not hide the assert() in a function whose sole purpose is to
call assert().

Change-Id: I7a8a04aad560b0f22398daabf12d00bbe58e89f1

Change-Id: Ie90906f1ed8dc205850df3a48688f66b7a72a4f4
Reviewed-on: https://gerrit.libreoffice.org/16343Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>

Change-Id: I809beb7187530cc30aca5dce8b2d4fb244554c55

Change-Id: Iddacb53071bb442845d702832f1728114ca018fa

Change-Id: I951c04e7d0039f1e38e3bcb2ea7e0f7c33293b9b

Change-Id: Ic9c4330e9b14e43448302132b6c01a8d93001d2f

Change-Id: Iea74564ef0ae2188ae29f106c4416df1fe827b42

...the only reason this didn't cause any problems is that the VclPtr returned
from Create already had an mnRefCnt > 1, because of activity in the PushButton
ctor.

Change-Id: I1066ff0b507b8a1ebff079f7b914235a7396368d

Change-Id: I56ed5047da118eac01d7dea150597133215278e2

... that take relative/absolute addressing and sheet 3D flag into
account to be fed to reference extension via range operator.

Change-Id: Iabe13ae384577e2d71ca87af6482ddccbf7ad0ac

Commit 194e9f9b oversimplified things.

Change-Id: Iea6a84c4a7be49af036690afbb1512ae2c1045a2

Change-Id: Ib32b299806851fd2df1fbe8a824c1fe49a4efd99

Change-Id: I9da47d7add4fadf34fd4e3c9aa6f1e65cf100b20

The problem is that the hints are iterated in order of start position,
and if there is a hyperlink inside a ruby then its end position will be
reached after the end position of the ruby due to the sort order, which
leads to overlapping XML elements.

So for any given position, first export the end positions, then the
start positions.

Change-Id: I2db28d7a36e4e34fbd394b3a69fe4549ee905250
Example: fdo82849-1.docx

If a hyperlink ends on the same position as a ruby starts, the hyperlink is
not closed before the ruby so its end tag is written inside the ruby
element.  Example: fdo82849-1.odt

Change-Id: I4531327ee23a99e366c2de5d9b08ddabb1be69c7

Change-Id: I33c51176b4497f1fcfe5a05d07741e8b74e7243b

Change-Id: Iae673ac8ed8e5817efefd665dbf5f061e80f94bc

Change-Id: I5089ce8e13d26dcc773f63b3a6f0ef17474444e0

Change-Id: I112e85d999a160b9b6393e924e981231d17f439d

They were removed in commit 18f41dfa by
mistake.

Change-Id: I0ed17471cd9d6ef19d401210ed530dab93c47865

I.e. the copy part of copy&paste. Only the Writer bits for now.

Change-Id: Ia003e76e3b234735f472cdef125514f9771d8640

Change-Id: I8a8d78b291c4b1fb6f0ef5d97cfae7c6a6ceaf64

Change-Id: I8ea68819a87abecb2a6561fbd5b695902dd4af63

Follow-up to commit 27384cdf:
avoid SwIndexReg::Update() correcting the index of CrossRefBookmark away
from 0.

Not sure if it wouldn't be better to remove the requirement that
CrossRefBookmark must have index 0.  Or perhaps remove the SwIndex from
their position completely, like AT_PARA frame anchors.  But since the
whole bookmark stuff stupidly uses inheritance the base class has
established a requirement that a mark has a position.  But then again
the CrossRefBookmark already cannot have a second position, in contrast
to all other marks.

Change-Id: If42cc48724de98151b02469850805f5c77e84c6b

was broken with 70f56bc2 "java: reduce scope,
make member classes private"

Change-Id: I84a3fafbfdddf6bb04ab7787d344bf50ffd22994

This may reduce some degree of dependency on boost.
Done by running a script like:

git grep -l '#include  *.boost/scoped_array.hpp.' \
 | xargs sed -i -e 's@#include  *.boost/scoped_array.hpp.@#include <memory>@'
git grep -l '\(boost::\)\?scoped_array<\([^<>]*\)>' \
 | xargs sed -i -e 's/\(boost::\)\?scoped_array<\([^<>]*\)>/std::unique_ptr<\2[]>/'

... and then killing duplicate or unnecessary includes,
while changing manually
m_xOutlineStylesCandidates in xmloff/source/text/txtimp.cxx,
extensions/source/ole/unoconversionutilities.hxx, and
extensions/source/ole/oleobjw.cxx.

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

...setting a new StepHelp value sometimes did not change the old value at all,
for whatever reason.

Change-Id: Id859091679bff96c1a3337bf32da42e7054cc166

Change-Id: I0c6390b54d0e9bb1cad7c30ff24ddb109d88e03b

Change-Id: I786b9590f8179a1f6c6593b7ff1dec286adda192

Many of our patches are now upstream.

Change-Id: I6c59973eea491148e92d7fa1a0b3681a9fcd2f2d

At least OutputDevice::acquire/release use a plain unguarded int and ++, --, so
apparently rely on the SolarMutex being locked whenever they are called.  Fixed
those places that caused "make check" to fail for me when temporarily adding
DBG_TESTSOLARMUTEX() to OutputDevice::acquire/release.  (A recurring pattern is
that a class fails to ensure the SolarMutex is locked around the destruction of
non-null VclPtr members.)

Change-Id: I77cba6f3908f2de1b516ce28f1c3c43b3f57a9c5