to make sure SfxBaseModel object is freed correctly
Found by: zhangjf
Patch by: zhangjf
(cherry picked from commit 4cb73634a602272d8de33dfe23722912e4494bbc)
Change-Id: I9e316178ef273b13e77d0b166f17fc700363f7bb
This reverts commit d256dbede60533369d1aac64cca34721183f6a8a:
For one, the new css.chart2.XTitle2 looked unfinished, in that it transfered the
direct properties of the old-style css.chart2.Title service into attributes, but
left out all the properties inherited by the old-style service from
css.style.ParagraphProperties, css.drawing.FillProperties,
css.drawing.LineProperties (and that missing FIXME css.layout.LayoutElement,
whatever that is supposed to be). This needs more thought, to either make
available all propertiers as attributes, or none.
For another, this broke JunitTest_chart2_unoapi (sch.ChXChartDocument,
sch.ChartTitle), for hard-to-debug reasons.
Conflicts:
chart2/source/model/main/Title.cxx
chart2/source/model/main/Title.hxx
offapi/com/sun/star/chart2/XTitle2.idl
sc/source/filter/inc/xlchart.hxx
Change-Id: I4747208a13984904d0e409ea49a73b0f667c86c7
API CHANGE: dropped the following services from the new unified
interface because the current service does not implement them.
service ::com::sun:⭐:style::CharacterProperties;
[optional] service ::com::sun:⭐:style::CharacterPropertiesAsian;
[optional] service ::com::sun:⭐:style::CharacterPropertiesComplex;
Change-Id: I7cb6a5d4e998975b1272f4f4da03feea30cd30b6
Enhanced EditEngine to be able to hold more than 64k paragraphs. Used
also in RTF import Calc and Writer, so that could benefit as well.
* changed all EditEngine,Outliner,... related paragraph index/count
variables from sal_uInt16 to sal_Int32
* sal_Int32 instead of sal_uInt32 to match accessibility API
* matched some Outliner methods' paragraph parameters from sal_uLong
to sal_Int32
* containers capable to hold size_t nevertheless are limited to a
maximum of sal_Int32
* changed definition of EE_PARA_NOT_FOUND and EE_PARA_ALL to
SAL_MAX_INT32
+ added EE_PARA_MAX_COUNT and EE_TEXTPOS_MAX_COUNT to initialize
ESelection with what previously were hard coded 0xFFFF all over the
place
+ for similar reason added EE_TEXTPOS_ALL corresponding to EE_PARA_ALL
to initialize an ESelection spanning all available text like
aSel(0,0,EE_PARA_ALL,EE_TEXTPOS_ALL)
Change-Id: I62d1b9c399cd709a4f93dbac31b219a61c46ec00
Reviewed-on: https://gerrit.libreoffice.org/3838
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
The boilerplate code for drawing the 4 types of stepped is in place (as
described in ODF1.3,
https://tools.oasis-open.org/issues/browse/OFFICE-3662).
We can also read the current attribute values used in Gnumeric. These values
are converted to ODF1.3 during save.
Change-Id: I0f04a779de4b65326ed7ce6de56191f11b51c596
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
The new header is <rsc/rsc-vcl-shared-types.hxx>, but if some other name or
location is cleaner, feel free to change.
Change-Id: I601923447ff7c1b6cefd71cb2652fcc88d2483d2
std::sort is unstable sort, which is not what we want. Use std::stable_sort
to sort data points by X values. If we use unstable sort, it may mess up
the order of the sequence when two data points contain identical X values.
Change-Id: I6453a986185b326dc680fbcec6227ea332235b22
This bug fixes two issues:
* Overlap detection seems to be approximate and
doesn't work for rotated text. Added a workaround
for labels rotated at angles 45-135 and 225-315.
* Auto rotate labels, which overlap. This is done
only for labels having zero degrees rotate.
For forcing angles, use 'enable overlap' or
non-zero angles (1 degree).
Of course, zero degrees plus skipping of labels
would no longer occur. Better solutions?
It works better this way for Excel interoperability. In Excel, Best fit
is slightly different than the center placement, but the two are pretty
close in pie charts.
Change-Id: I7f04a1babb04fd488d8cf90df247c294fa9d7b67
This value appears to control the logical vertical offset of data labels
along the z-axis for 3D pie charts (no effect in 2D pie charts). With
-0.5, the data labels appear lifted from the top surface of the pie chart.
With -1.0, the labels get placed right at the top surface, which improves
the precision of data label positions.
With this change, data labels that are centered are really centered inside
their respective pie segments.
Change-Id: I26d5d7cb7f68bd09131b70bcb4fc030ac924bcce
