Patch-by: Thorsten Wagner <thorsten.wagner.4@gmail.com>
Reviewed-by: Herbert Duerr <hdu@apache.org>

for #i124928, rich text portion could be converted several times, each time when it is converted, the string will be set once, but in the setString logic, the text is inserted instead of set.

Repeated conversion is unnecessary, add a flag to avoid repeated conversion

124966: keep picture format information - <GfxLink> instance - also for the reading of preview picture data

in order to avoid trouble on save in case that the preview data equals the picture data

- needed correction for the fix made for issue 114361

124877: method <SwTxtNode::RstTxtAttr(..)> - correct refactoring (made for issue 123389) causing serious endless loop

Setting a fixed default font height parameter doesn't make much sense when
neither the target device nor its mapping mode nor its target resolution are
known. This change reverts revision 1589449 of bug 124686 that has already been
solved differently and restores the previous behaviour so that the default height
of default constructed fonts is set to 12pt when the target device becomes known.
Reviewed-by: Armin Le Grand <alg@apache.org>

on trunk the 4.1.0 build target product name is obsolete after AOO 4.1 was
branched off and released. This change tentatively updates it to 4.2 which is
the anticipated name of the next release to be branched of from trunk.
Reported-by: Rainer Bielefeld <rainerbielefeld_ooo_qa@bielefeldundbuss.de>

clean up some minor warts while the behaviour remains unchanged.

A problem with horizontal scrolling was reported on Mac. Reviewing the relevant
code identified some problems. The patch to fix them was confirmed to also fix
the reported problem.

Found-by: erben.fr@gmail.com
Tested-by: cemonadresse@orange.fr
Tested-by: TrolliusX@t-online.de
Tested-by: thorsten.wagner.4@gmail.com

the concept of an extra-width per code-unit was obsolete at least since apps
supported unicode with its different normalization forms, diacritical marks,
surrogate-pairs, non-printing characters such as ZWJ/ZWNJ/RLM, etc.  so of
course modern engines like CoreText don't aid this typographical crime.

The fix here extends the CTLayout::GetTextBreak() method to handle the obsolete
semantic of per code-unit extra-widths by successively approximating the number
of involved code-units.

Found-by: Rainer Bielefeld <rainerbielefeld_ooo_qa@bielefeldundbuss.de>

Patch-by: Thorsten Wagner <thorsten.wagner.4@gmail.com>

with the sal-internal custom allocator removed AOO no longer needs the
stlport-replacement headers to support the complexity of containers with
non-default allocators. Xcode>=5.1's libc++ runs into build problems with
such custom allocator support in the stlport-replacement headers because
of constness mismatches.

chapter 8.3.6.4 of the C++11 standard requests that friend declarations must not
specify default unless these declarations are also definitions. Older compilers
still tolerate such constructs that were still undecided until
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#136
but clang>=3.4 or xcode>=5.1 now report errors for such code. The errors break the
build and so they have to be fixed. Cleaner alternatives to the fixes are possible
but for now they are intended to allow the build while being minimally invasive.

implicit conversions from bool or int32 to pointer types are not a good idea
and clang>=3.4 or xcode>=5.1 now report errors for such code. The errors break
the build and so they have to be fixed.

comparing pointers with bools or integers is not a good idea and
clang>=3.4 or xcode>=5.1 now report errors for such code. The
errors break the build and so they have to be fixed.

The SAL module avoided the heavy dependency on the stlport4-libraries by using
a custom allocator for its internal STL containers. With stlport4 removed these
dependencies are gone and the SAL-internal custom allocator is obsoleted. Since
the custom allocator results in build problems with clang>=3.4 or xcode>=5.1 it
is time to remove it for good.

in AV Foundation the most accurate media asset duration is available when the
AVPlayerItem's status changes to AVPlayerItemStatusReadyToPlay. There already
is an observer for this, but the upper layers expect getDuration() to be
synchronous and to return within a reasonable time. Since returning an
approximation is sufficient using the AVAsset's duration as fallback is fine.

FrameGrabber used to load its own copy of a movie. Since multimedia content
is often very data-intensive this should and can be avoided by using the
movie asset already available in the Player.

in the dmake build environment active header and source files with the
same name result in problems when in the same project. The Quicktime and
MacAVF files have been renamed so that both can be active concurrently.

While XCode5's xcode-select supports the -p and --print-path options, XCode4
officially only knows -print-path. XCode4 seems to tolerate --print-path though
(tested on XCode4.6), so this can be universally used.
Patch-by: Thorsten Wagner <thorsten.wagner.4@gmail.com>
Review-by: Herbert Duerr <hdu@apache.org>

because the QuickTime API is not available to 64bit clients. The switch to QTKit
is temporary only because it has already been deprecated in OSX 10.9. We'll have
to switch to OSX's AVFoundation framework instead soon.

Suggested by: Ariel Constenla-Haile <arielch@apache.org>