There was code that was inserted by commit id
'8c178a50334109b34ef456ca6aa51cd3d98699ae' that added logic to
also export 'rPr' in the 'pPr' node.
The 'rPr' represents the paragraph marker formatting.
However - simply copying the last run's formatting and assuming
it is the same for the paragraph marker should not be used.
Also refer to 'aafffe6d1c3734fb2acef4b2bb1385c1e2f49043' for
details on test-case disable.
Change-Id: I6004e4c706abfeb5f51d86d11d3ebf46256a68c5
Reviewed-on: https://gerrit.libreoffice.org/7121
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's not terribly nice, but, hopefully, better.
The hope is that one day, lo_get_library_map will be no more.
In lo_get_implementation_map we can specify more precisely what to link
into the binary.
Change-Id: I99a1854fbae05be2f70302cc56bea88e522ec129
Demonstrating on expwrap library.
There is hope, this will bring code size savings for mobile
platforms, where we don't need every implementation.
Change-Id: I3519fb6148fd7a47ed9df092c73779ea6add552f
a new log section (sal.rtl.xub) is used to display alert in case of
suspicious len == 0xFFFF (aka STRING_LEN)
Change-Id: I3ed2aa7896e12592be9e003580dd6c8eda4add5e
Reviewed-on: https://gerrit.libreoffice.org/7117
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Class XMLNumberWithAutoInsteadZeroPropHdl (which appears to be used only
for this attribute) needs to be adapted to the change that
"PageNumberOffset" value 0 is no longer invalid; use "void" value for
invalid instead, which appears more appropriate anyway.
Unfortunately the type of style:page-number is positiveInteger so
writing 0 would be invalid; write "auto" instead for now.
Change-Id: I9621ea201fd928087b863c562607c3d77a3b0269
The property is called w:themeColor and it belongs to the w:color tag
inside run properties.
On import, the themeColor prop is stored in the character interop
grab bag together with the val prop.
On export, the current color of a text run is compared with the
stored val prop to know if the color has been changed during the
document edition. If it hasn't changed, the themeColor property
must be written to the document; if it has, it must not be written to
avoid overwriting the new color.
Also added a unit test for this property.
Change-Id: Icc95ee023aecc741adcba23d23206aadd6c30e1f
Apparently SvxTextEditSourceImpl::mpView is not properly invalidated
when the instance it points to is deleted; the SvxTextEditSourceImpl
is registered as listener so try to handle this in Notify(); not sure
if there isn't something that ought to have cleaned this up...
Crash running with SAL_FORCE_IACCESSIBLE2=1:
svxcorelo.dll!SdrPaintView::FindPaintWindow(const OutputDevice & rOut) Line 70
svxcorelo.dll!SvxTextEditSourceImpl::GetVisArea() Line 923
svxcorelo.dll!SvxTextEditSource::GetVisArea() Line 1113
svxlo.dll!accessibility::AccessibleTextHelper_Impl::UpdateVisibleChildren(bool bBroadcastEvents) Line 868
svxlo.dll!accessibility::AccessibleTextHelper_Impl::ProcessQueue() Line 1376
svxlo.dll!accessibility::AccessibleTextHelper_Impl::Notify(SfxBroadcaster & __formal, const SfxHint & rHint) Line 1530
svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 48
svxcorelo.dll!SvxTextEditSourceImpl::NotifyHdl(EENotify * aNotify) Line 1021
svxcorelo.dll!SvxTextEditSourceImpl::LinkStubNotifyHdl(void * pThis, void * pCaller) Line 1013
tllo.dll!Link::Call(void * pCaller) Line 123
editenglo.dll!Outliner::ImplBlockInsertionCallbacks(unsigned char b) Line 2098
editenglo.dll!Outliner::Clear() Line 2036
svxcorelo.dll!SdrOutlinerCache::disposeOutliner(SdrOutliner * pOutliner) Line 91
svxcorelo.dll!SdrModel::disposeOutliner(SdrOutliner * pOutliner) Line 1960
svxcorelo.dll!SvxTextEditSourceImpl::dispose() Line 489
svxcorelo.dll!SvxTextEditSourceImpl::Notify(SfxBroadcaster & __formal, const SfxHint & rHint) Line 458
svllo.dll!SfxBroadcaster::Broadcast(const SfxHint & rHint) Line 48
svxcorelo.dll!SdrModel::~SdrModel() Line 270
chartcorelo.dll!chart::DrawModelWrapper::~DrawModelWrapper() Line 191
chartcorelo.dll!chart::DrawModelWrapper::`vector deleting destructor'(unsigned int)
chartcorelo.dll!boost::checked_delete<chart::DrawModelWrapper>(chart::DrawModelWrapper * x) Line 34
chartcorelo.dll!boost::detail::sp_counted_impl_p<chart::DrawModelWrapper>::dispose() Line 78
chartcorelo.dll!boost::detail::sp_counted_base::release() Line 104
chartcorelo.dll!boost::detail::shared_count::~shared_count() Line 381
chartcorelo.dll!boost::shared_ptr<chart::DrawModelWrapper>::~shared_ptr<chart::DrawModelWrapper>()
chartcorelo.dll!boost::shared_ptr<chart::DrawModelWrapper>::reset() Line 626
chartcorelo.dll!chart::ChartView::~ChartView() Line 202
chartcorelo.dll!chart::ChartView::`scalar deleting destructor'(unsigned int)
cppuhelper3MSC.dll!cppu::OWeakObject::release() Line 204
chartcorelo.dll!cppu::WeakImplHelper10<com::sun:⭐:lang::XInitialization,com::sun:⭐:lang::XServiceInfo,com::sun:⭐:datatransfer::XTransferable,com::sun:⭐:lang::XUnoTunnel,com::sun:⭐:util::XModifyListener,com::sun:⭐:util::XModeChangeBroadcaster,com::sun:⭐:util::XUpdatable,com::sun:⭐🫘:XPropertySet,com::sun:⭐:lang::XMultiServiceFactory,com::sun:⭐:qa::XDumper>::release() Line 115
chartcorelo.dll!com::sun:⭐:uno::Reference<com::sun:⭐:uno::XInterface>::~Reference<com::sun:⭐:uno::XInterface>() Line 106
chartcorelo.dll!chart::ChartModel::~ChartModel() Line 188
chartcorelo.dll!chart::ChartModel::`vector deleting destructor'(unsigned int)
cppuhelper3MSC.dll!cppu::OWeakObject::release() Line 204
Change-Id: Ife6d6275eae74750858a7a7f57153c76a1a228a4
This crashed here once during some JunitTest with an rDescriptor that
did not match maVisibleChildren.back().
[The mrContext member used here is const so shouldn't cause problems.]
Change-Id: I31e54b166badef6472127c64f0a4f49c51c73b30
76c549eb01 changes some calls to
SwAccessibleChildSList to use the PaintArea() of the given SwFrm
instead of the given rVisArea, which makes
SwAccessibleFrame::GetChildCount() and GetChildIndex() inconsistent
with other methods such as GetChild(), GetChildAtPixel() etc.
Not sure which way is better, but it should be consistent;
revert the partial change for now and see.
Change-Id: I7d7edf2ec3dd0860ac2331d36757096186185e4f
...which it did unlike all the other implbaseN.hxx. Required lots of downstream clean-up,
of course.
Change-Id: Ib720e7a0a43410dcd7e6338b84a3973dfbb20866
...otherwise at least my --disable-dbgutil --disable-debug Linux x86_64 build
failed the CppunitTest_sax_cpputest with 8999999 vs. 9000000 nanoseconds.
Change-Id: I05e0febf413f9f9e01227a0cc4e0f46a5243fe61
This is triggered by testVMLData in CppunitTest_sw_ooxmlexport when DML export
is enabled in non-experimental mode.
Change-Id: Id636b1ab701ff49da1b05b720fcb2173360584ba
This is triggered by testVMLData in CppunitTest_sw_ooxmlexport when DML export
is enabled in non-experimental mode.
Change-Id: I5e157f75909d05fc18d9a8790839030f4056860d
ARCHS tells Xcode to build the architecture for which the LO code has
been built. The CFLAGS properties make sure the same -D flags are used
as for the LO code.
Change-Id: I3c8af0ff9fba7d0b4eddbc0af9aad44fb385314c
Constants CURLPROTO_HTTP, CURLPROTO_HTTPS, ... have been introduced in curl 7.19.4.
With current requirement (>= 7.13.1), we would get build errors like
"cmis/src/libcmis/base-session.cxx:841: error: CURLOPT_PROTOCOLS was not declared in this scope"
in cases of using curl < 7.19.4.
Change-Id: Ifa6c56fc71715cceb19d30bb2d6f48f0b1dbd7da
Reviewed-on: https://gerrit.libreoffice.org/7050
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
It is the same as Linux@PowerPC 32-bit (cp -r gcc3_linux_powerpc gcc3_macosx_powerpc),
with differences applied:
* Use 13 FP registers and correct 'codeSnippetSize' (8*4 + 13*8 = 136).
* Use "frame pointer + 24", not "+8".
* Don't USE_DOUBLE_MMAP and 'sal_PtrDiff writetoexecdiff'.
* Don't use "__NO_FPRS__", OS X capable PowerPC machines all have FPRs.
* Use "rN"/"fN" syntax to avoid "Parameter syntax error" errors.
* Include sys/types.h, sys/malloc.h instead of malloc.h;
don't include string.h.
Change-Id: I5b251c65466af2a06bd309d3a7b1aaf26ac12656
Reviewed-on: https://gerrit.libreoffice.org/7072
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
progress thread blocked on solarmutex
press cancel in main thread which has solarmutex locked
call terminate
call join, which waits for thread to finish, which it can't
because its waiting on the locked solarmutex
so...
just call terminate on cancel. Let the thread get the solarmutex
and do its last round of work, at which point it will exit and post
an event to the main thread to call Cleanup, put the join there
instead and which point we know the progress thread is finished and
has no more interest in the solarmutex.
Change-Id: Ibe3976377288ac76b1b37c875a32e20b8d5daae1
At least what we wrote previously is not accepted by Word and even Word
2013 writes watermarks as VML-only.
This fixes testWatermark in CppunitTest_sw_ooxmlexport when DML export is
enabled in non-experimental mode.
Change-Id: I231014dd7ad60b5a4b0d79e76cdc3386641af032
