Age | Commit message (Collapse) | Author |
|
Change-Id: I39b12a6290d13a5404dae60b0b16548b035f24d8
|
|
Change-Id: Ia76df719b2f76a993e65e0bf6d55723b1a2f5b93
|
|
Change-Id: I0d89cc99a1d8f7b3c17986b45653dce5e4b436d7
|
|
Btw, th unanounced byte-swapping of valuse in the input array in
writeArray seems a bit dubious to me... It could too easily cause
unintentional memory damage. I just hope it is always called either with
data that is not used after that anymore or with a copy of the data.
Change-Id: Ica0e9ea16cd101fe87d7e0a8fa696911769e0654
|
|
Change-Id: I2cc9884b23b49eb3e2afd27e5610bf96998a3c7f
|
|
This reverts commit 47a2d7642d249d70b5da0c330a73f3a0032e4bba.
Conflicts:
cui/source/tabpages/transfrm.cxx
svx/source/svdraw/svdedtv1.cxx
svx/source/svdraw/svdibrow.cxx
sw/source/filter/ww1/w1filter.cxx
tools/source/generic/rational.cxx
Change-Id: I4849916f5f277a4afef0e279b0135c76b36b9d15
|
|
This reverts commit 582ef22d3e8e30ffd58f092d37ffda30bd07bd9e.
Conflicts:
svx/source/svdraw/svdedtv1.cxx
svx/source/svdraw/svdibrow.cxx
sw/source/filter/ww1/w1filter.cxx
Change-Id: I80abc7abdeddc267eaabc9f8ab49611bb3f8ae83
|
|
Change-Id: Icd9c6ebc9feb3e7aba28b01729b582a8f49c832a
|
|
Change-Id: I8d6df8c6853f0bd2f0b099d14bf0ac246170e7f1
|
|
Fraction used BigInt internally for computations, rational does nothing
like that.
Change-Id: I3e9b25074f979bc291208f7c6362c3c40eb77ff5
|
|
...detected with a modified trunk Clang with
> Index: lib/Sema/SemaDeclCXX.cpp
> ===================================================================
> --- lib/Sema/SemaDeclCXX.cpp (revision 219190)
> +++ lib/Sema/SemaDeclCXX.cpp (working copy)
> @@ -1917,9 +1917,10 @@
> const Type *T = FD.getType()->getBaseElementTypeUnsafe();
> // FIXME: Destruction of ObjC lifetime types has side-effects.
> if (const CXXRecordDecl *RD = T->getAsCXXRecordDecl())
> - return !RD->isCompleteDefinition() ||
> - !RD->hasTrivialDefaultConstructor() ||
> - !RD->hasTrivialDestructor();
> + return !RD->hasAttr<WarnUnusedAttr>() &&
> + (!RD->isCompleteDefinition() ||
> + !RD->hasTrivialDefaultConstructor() ||
> + !RD->hasTrivialDestructor());
> return false;
> }
>
> @@ -3517,9 +3518,11 @@
> bool addFieldInitializer(CXXCtorInitializer *Init) {
> AllToInit.push_back(Init);
>
> +#if 0
> // Check whether this initializer makes the field "used".
> if (Init->getInit()->HasSideEffects(S.Context))
> S.UnusedPrivateFields.remove(Init->getAnyMember());
> +#endif
>
> return false;
> }
to warn about members of SAL_WARN_UNUSED-annotated class types, and warn about
initializations with side effects (cf.
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039602.html>
"-Wunused-private-field distracted by side effects").
Change-Id: I3f3181c4eb8180ca28e1fa3dffc9dbe1002c6628
|
|
from oox::core::Relations.
Change-Id: If2e0109a2ad6598436177b7638cb6d568fb2d3d6
Reviewed-on: https://gerrit.libreoffice.org/11899
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
* Added rational util functions used by Fraction class not
available in the boost::rational class.
* Replaced usage of Fraction by boost::rational<long>
* Removed code that relies on:
1. fraction.IsValid() -- rational only allow valid values, ie
denominator() != 0
2. rational.denominator() == 0 -- always false
3. rational.denominator() < 0 -- always false but implementation
detail: http://www.boost.org/doc/libs/release/libs/rational/rational.html#Internal%20representation
* Simplified code that relies on:
1. rational.denominator() != 0 -- always true
* BUGS EXIST because Fraction allows the creation of invalid values but
boost::rational throws the exception boost::bad_rational
Change-Id: I84970a4956afb3f91ac0c8f726547466319420f9
Reviewed-on: https://gerrit.libreoffice.org/11551
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
from ItemFormatMap.
Change-Id: I956b5797e677d22eb71fe801b650db7c982d6d51
Reviewed-on: https://gerrit.libreoffice.org/11854
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I99f3010e30f81786b938dc11736ea1597cd5530d
|
|
Put the TOOLS PolyPolygon class in the tools namespace. Avoids clash with the Windows
PolyPolygon typedef.
Change-Id: I811ecbb3d55ba4ce66e4555a8586f60fcd57fb66
|
|
Change-Id: I35d3cc04eb9bbc8b4446bc501ba35e058c1aa34a
|
|
Change-Id: I778dc43085b6afbb6456cbf53fe8c95b624b75b3
|
|
Change-Id: I8165def0b6291bfd7bb109e1cdaeb4198ed696b7
Reviewed-on: https://gerrit.libreoffice.org/11560
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
|
|
Change-Id: I0d8072f1194aa837932dcffd6dc6a3761bbdc74e
|
|
This is similar to 7b8073906adca8dae24c04a23708a3f3d582218f (Ensure we
export correct labal placement value for percent/stacked charts.,
2014-08-07), in case a clustered bar chart has a top placement ("t" in
OOXML), then MSO complains as well.
Change-Id: Iffd991127784e0e732f6ae55de956a328a3a53e5
|
|
Do not export LinePropertiesContext class as visible.
And move GraphicProperties to its own header.
Change-Id: I047c181e9f2adc7e59885f59663ea56c7eb898ed
|
|
To make 'if (rBackgroundFillStyle.mnThemedIdx != 0)' actually work
as intended. Avoids invalid call to pTheme->getFillStyle() which
is not supposed to return 0 here.
Change-Id: I323e2628cba64167240e8f0b945e6693b47b8e77
|
|
Change-Id: Ie94573f7c43c834cd636493bed32f07aa792da49
|
|
Change-Id: I90847d0edbc2c13e405562647b150012bc5df7e2
Reviewed-on: https://gerrit.libreoffice.org/11249
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Still not perfect, but it somewhat does work.
Change-Id: Ic248e20f7ab18a37f56b2034f57551dded956bab
|
|
Change-Id: I5634bf40e8ccc4ce076409907c13f9c6f52d11a3
|
|
Change-Id: Icc32c336495a1d0a29b24b976dd5f359d03a0bba
|
|
Placeholder type seems to be more relevant than index.
Change-Id: I9d6c6cad8e0a51b2385801f65d7d1c697ad7998e
|
|
Possibly they did something different in the past, but currently they do
the same. This commit just switches the handler, the newly unused code
will be removed in a later commit.
Change-Id: Ic5bade876c264e025543728916d9bcd871e32b9b
|
|
MS Office has trouble loading the file if you do. There is an exception,
however. A pie chart allows label placement option even when 3D. There
may be other chart types that allow variable label placement when 3D.
Change-Id: I6a9247041ca6ee3ae1b9c245f5919fcb35951f24
|
|
Charts in docx and xlsx OTOH use solid white as the default fill style.
Change-Id: Ic4351fe65cabc12d60214b67c7026a317841f2c7
|
|
|
|
Change-Id: Ib332d04fa27501ec35267b5e389c2979c9c55be2
|
|
- Generic fix for all warp properties
Change-Id: I77c37759aa49706fc3cd1a80770a85face53f0a2
|
|
Change-Id: I9e49abc490935710b471c79d19385bda37f038b0
|
|
- Rotation property is not available for TextFrame in LO.
- Hence grabbaged this value.
- Roundtripped rotation value by converting it properly for both dml and vml textbox.
- Added UT for it.
Change-Id: Ia040d55dc2ea79500df76877ba44a02971c872a8
Reviewed-on: https://gerrit.libreoffice.org/10190
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
and
coverity#1224994 Uncaught exception
Change-Id: I7f25e3829dbd1e5d68561ca9853ab8fc10c79484
|
|
and
coverity#1224996 Uncaught exception
Change-Id: I36ea602a93471d826859bef739c4165117cc4cd9
|
|
Otherwise wrong colors are displayed.
Change-Id: I5d7444100355fdbc5fcd2aaa1c01202ace54312d
|
|
regressions around inserted extra enum values
into ShapePropertyId
Change-Id: I06696c8cfe4acc3836723c31d5e714bd7d8439b3
|
|
We need to pass the role of the data sequence in order to avoid unreliable
guess work when importing static value array.
Also, not all Excel's scatter plots have real numeric X values; some have
textural X values in which case Excel switch to generating 1, 2, 3, ... as
X values. When importing to our chart implementation, using "categories" role
in such cases instead of "values-x" results in a more faithful chart rendering.
Change-Id: If4bc1f650bb024dcd1b1b36537f457fb38404a78
|
|
Change-Id: I7c3f115520d8c6a1fba997aeedddf96c01780e7e
|
|
Change-Id: Icef20c193a64b7de410e21124edaa4d0699d8a66
|
|
Change-Id: I0963c92356f8388ce02fb36e172ad3b2af8ba8f8
|
|
Change-Id: I9de33fdcd8b1ef73d57884033f502ac4a03f63d3
|
|
Change-Id: Ic63372285fecb6f1be22e92c36cdb6f94733f5c1
|
|
Change-Id: I6d5a952901648e01904ef5c37f953c517304d31e
|
|
Previously, we always exported the text of the shape itself. Bring the
VML export in sync with the drawingML export, where we only do that if
the shape doesn't have an associated textbox -- if that's the case, then
export the textbox's text instead.
CppunitTest_sw_ooxmlsdrexport's testFdo69636 is a reproducer for this
problem, the VML assert failed because of the lack of this.
Change-Id: Icb236579da4e3b74e983a95aa5675fed7862d1e1
|
|
The import mechanism of custom-dash (a:custDash) was wrong, and imported
wrong values, which causes that if you would import-export-import-export -
you would get inflated values, which might cause a corruption.
The attributes for custom-dash nodes (a:ds) are of type 'PositivePercentage'.
Office will read percentages formatted with a trailing percent sign or
formatted as 1000th of a percent without a trailing percent sign, but only
write percentages as 1000th's of a percent without a trailing percent sign.
During import - LO did not check if it was in '%' format or in
'1000th of a percent' format. So that was fixed. Also - when exporting -
it always exports now in '1000th of a percent' format.
Change-Id: I6bd74df26951974f85173227c832386c70034afb
Reviewed-on: https://gerrit.libreoffice.org/9681
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|