Change-Id: I791e55bb5d98ee82c01271dcebafa7c4672cd424

Change-Id: Ib080dd7fcbc8abb52f762a8071b0233e970b2691

Change-Id: I166e40e7b6d91fa406f9f3649001c12f054bbf2a

Change-Id: I81725b388311ad9aade52906b4c5a6263b6bc104

But do we want to keep that code still around? I would love to drop
it. Using only CoreText would make some planned refactoring of OS X
and iOS code much simpler.

Change-Id: I9514c254791ea462d528e3e83b4927ac62a9f6ca

Change-Id: I5b98eecc55dbb89fa0f4127f437e0e8cc798eb86

Change-Id: I969b17ffe89e5fbb0f30a47acecaf6698e81fefe

Change-Id: I07a50583990325e83bf9a27fba0194c3a277eea6

Change-Id: I5e99fbedf21fcf4a84f4695ca5aa3fd56259e849

Change-Id: Idafbd9fb3fb71a1da9ba6b7a39007eac3865c932

Change-Id: Ia63c8c6207c9c3add3d8d89cafd687df287456ef

Change-Id: Ifa3621a21e03aff313198fc29044b93c8f57001c

Change-Id: I7004150569e5329f19d2f08adbd70477bd6252ff

Change-Id: I2c9d1a82ec0159fae80a8e146d1218aa98895f65

Change-Id: Iefe2cd87f499e624cbd3bd2583f6f0df90f4b4cb

Change-Id: Iea706d316d731fb57f7021e99a11d1487a2ee5b8

Change-Id: Id926b139b14ee667ce4ac0674a3c090b52680649

Change-Id: I2e76d19986326b15c088e6dcce1da3be3924d0fc

This breaks windows build with localized versions of MSVC.

Change-Id: I23c46830f96ae661eced88352476e7ae61fbcc2a
Reviewed-on: https://gerrit.libreoffice.org/6847Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: Ib3e6705d166dec9d7db8787496947faf73e3cfb3

Rename the CoreText-specific ImplMacFontData class to CoreTextFontData
and unify it with its sole derived class CTFontData.

Change-Id: Id3540432996ca55b2e4a20fd8798c94cb7bc84b6

Change-Id: I5c6986b4c765c8328cacb84ce84cc99eb6871d0a

No need to hide stuff from ourselves at multiple levels. Rename the
CoreText-specific ImplMacTextStyle class to CoreTextStyle and unify it
with its sole derived class CTTextStyle. This is all internal to vcl
anyway.

Change-Id: Ib9e632ccba5c273200d4e3fce79a97db305c6662

Change-Id: I002d1d9b3a0194e9d0f404798698a8c2353021b1

Change-Id: I674b86a6e1c1c0b162c159747b6900ce438ab095

Change-Id: Ic84ace8ac3aa52009f43aafe78283730f97881f2

Also fixes memory leak, because EnableUndo()
was called from Document's destructor.

Change-Id: I637ff62bde6f8c3238238323e6e4a5a5d2b81881

The code is copied and simplified from sc/source/ui/docshell/impex.cxx.

Change-Id: I15a426a16c4f2ba659af86492c1b2e4ba879d8b6

Change-Id: I76a11dae2569eb7e0c791c9f1fb20626c4ff7528

As was the original idea, for some reason abandoned, and as ScAreaLink does.

The main advantage is that ImportData() is not called anymore with
invalid mpScDocument (when we close it).
There is surely something going on with SolarMutex and it just works better.
We do not need to use our own SolarMutexGuard.

Change-Id: I09256a18ffa14606fc8e06b968016bbc0562a6fa

Change-Id: Ibb456da55f04c39ddb7b58eb71ca488cf209edb5

Fix ScXMLExport::GetAreaLinks to not use UNO, so we can hack DataStreams
into ScMyAreaLinksContainer.
We need to connect them to cells for export / import - that does not make
sense for DataStream without any attached range. We use an arbitrary one.
But you might remove it, if you create another ScAreaLink / DataStream
with the same range, without knowing about it.

Maybe it wouldn't be that bad to let DataStream inherit from ScAreaLink.

Change-Id: I5b85a9329ba1ca46fb2893b54fe5161d2fb22f47

Change-Id: I18db991d2e8e665d5e4ca778344993e79772ccd5

By inheriting from sfx2::SvBaseLink and storing in sfx2::LinkManager we can
have more data streams and see / remove them in Edit -> Links... dialog.
Also rename to DataStream to avoid confusion.

Change-Id: I9c3b89020324af7be082f9e6e1cd479aeb72fe81

Change-Id: I57064ff251a560b71aaf1846a9d7cd9105f938df

Change-Id: Ic7e0b943749266646722cf6525e77b006ae79232

There were quite some unrelated content in these test documents...

1m24.754s -> 1m4.757s

Change-Id: I5e12a4c82c8c6f4454d2b2113d11aa289e125832

This way a 2>/dev/null output still gives a csv, even if there were
various other warnings in the meantime.

Change-Id: I6ed3de4058c829e856286c7d484d6ed436c362a4

Basically reverts the pieces of
21ec9bea to make XSpriteCanvas a
XBitmapCanvas again

Otherwise PresenterHelper::loadBitmap is not an XBitmapCanvas
and so VclFactory::createBitmap cannot succeed

Change-Id: I197adf98e915102f383ee050a8ea16d1e41cecf2

... since inception in 44569a65 "CWS-TOOLING:
integrate CWS bubblechart."

Change-Id: I1785ef41bf7146ea7f4d8927165c38317d7183e8