Age | Commit message (Collapse) | Author |
|
This reverts modifications to existing unit tests made in commit
d0a1616ccad0dd5f5a02c1b0204f537b57d0b4b5. My idea that those changes
were required because of more correct calculations was wrong, and in
fact they were caused by off-by-1 error in height calculations.
Change-Id: Ib94878a911238c977c35a8f8e3e5694cedc79a89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118705
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
/** If a value is a valid argument for sin(), cos(), tan().
IEEE 754 specifies that absolute values up to 2^64 (=1.844e19) for the
radian must be supported by trigonometric functions. Unfortunately, at
least on x86 architectures, the FPU doesn't generate an error pattern for
values >2^64 but produces erroneous results instead and sets only the
"invalid operation" (IM) flag in the status word :-( Thus the application
has to handle it itself.
*/
chart2/source/tools/RelativePositionHelper.cxx
Function name: RelativePositionHelper::getCenterOfAnchoredObject
From here: suppose it's related to the orientation of the chart << 2^64
chart2/source/view/main/LabelPositionHelper.cxx
LabelPositionHelper::LabelPositionHelper
Suppose: setup label position.
There won't be angles grater than 360º.
chart2/source/view/main/PlottingPositionHelper.cxx
PolarPlottingPositionHelper::transformUnitCircleToScene
Suppose: maybe disc chart orientation?
Internal angle should be safe.
chart2/source/view/main/ShapeFactory.cxx
ShapeFactory::getSizeAfterRotation
Suppose: rotate shape
Internal angle should be safe.
drawinglayer/source/processor2d/vclmetafileprocessor2d.cxx
Constant 100% safe
sc/source/core/data/documen4.cxx
bool ScDocument::Solver
Suppose: the tangent is being used as numerical derivative (Regula falsi algorithm)
So no impossible angles
scaddins/source/analysis/bessel.cxx
Filtered it out as bad imput
Change-Id: Ib348cca6ce13263d087b6731f93f58d8a15cc725
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118193
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I71af8273c672a4cbcbfefafffd0003ab266dcce6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118132
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If8794c105e279afd4437517d3e61f2f900eb6490
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118123
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
can be a little expensive sometimes, since it loads a bunch of other
stuff at the same time.
So create a custom method that just loads the version
Change-Id: Ic480d95c4d64c68e57faf1b52f1d102141b7e246
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118047
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The algorithm in Numerical Recipies in C, 2nd edition in Section 3.3,
page 166 states a division rather than a multiplication.
Change-Id: I2530c506bc48726539e3de99016892e50d6bb87e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115465
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
Attaching a data series to the secondary axis didn't enable
the secondary axis at the right side of the chart using the
sidebar (unlike in data series local menu -> Format Data
Series... -> Options).
Test: Click on the chart, select one of the data series, and
enable Data Series -> Align Series to Axis -> Secondary Y Axis.
Change-Id: I2cb99458af724471d4d04cac8c2c9013f41634fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117048
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Chart Type dialog was empty, when the chart type of the chart
was unsupported.
Regression from commit: 4ff983b930dc15658aa531759d3f1e5b9586aeab
(Related: tdf#142049 restore some elements default visibility
in the ui)
Change-Id: I057e6b9218edee398af8311c46b922ca76a9bcb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117173
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I8a17c36489946327113e63f80b952525ae4201a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117377
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0bb0ea9d39ed623928060ffd3f2e2bc36ba33209
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117272
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I68629d4350c43c80fdd00f9fcb8af3733753fe43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117327
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Makes footer, slidenum and datetime placeholders that are inserted to
the slides themselves on pptx files imported as slide properties if it
is possible to do so without losing information (style, position etc.)
If that is not the case and the footers have some special style applied
to them that isn't inherited from master slides, fallbacks to the current
implementation importing them as shapes.
Also since the default way of displaying slide footers in LO use the
respective text fields on master slides, information in master/layout
slide datetime and footer placeholders respectively get replaced with
<date/time> text fields and <footer> text fields.
Change-Id: Ib2f7d18103b62c0c9a8453e01cfd2fd1aa1d39af
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117008
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I1a9b98b9e20fd6e097bc8fd68958b7feb66991f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117236
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I96e191999e43e1a4203d548eeacd386ed883cd8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115368
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I0475bdd0633b54a644e205628577fac18a3af974
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117142
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I79cc2032c8641288ec6def4aaee32cb67e2da915
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117140
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
This allows to make sure we actually use sorted which ranges,
and then it's safe to call SfxItemSet::MergeRange when needed.
Also this change relaxes the previous requirement that ranges
must be separated by at least one; this allows to have adjacent
ranges, like in
RES_FRMATR_BEGIN, RES_FRMATR_END-1,
RES_GRFATR_BEGIN, RES_GRFATR_END-1,
where RES_FRMATR_END is equal to RES_GRFATR_BEGIN. Allowing this
makes possible to (1) self-document the ranges, so it's clear
which ranges are included; and (2) be safe in case when these
constants would change, so that the one merged range would not
unexpectedly contain everything inserted between RES_FRMATR_END
and RES_GRFATR_BEGIN.
Change-Id: Iaad0f099b85059b3aa318a347aa7fbd3f6d455c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116909
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Icf8972be204799e9b3b3824ab18d8584911fe1c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117061
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
During the import of the internal data table, incomplete
parsing of category labels with escaped quotation marks
resulted broken category labels and charts.
Change-Id: If5af3d527b80d1e055562f589bdaf17096ad49f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116714
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
where the secondary axis is supported by the chart model
and OOXML.
Change-Id: Ifbcc905139487965510063aa87991ce6f8df73ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116809
Tested-by: Jenkins
Reviewed-by: Balazs Varga <varga.balazs3@nisz.hu>
|
|
it already had 148 tests
Change-Id: I83e0055bcf1449cd48a28149a6ef0b149a1d6901
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116914
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I2ee15ec29fbf5fc4fcaea035a9cd99ba49453a4e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116831
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
This changes the way how different parts access positions of lines and
paragraphs. Now there is ImpEditEngine::IterateLineAreas, which performs
uniform iteration over all ParaPortions and lines in order, calling a
user-provided callback function for each portion and line; it passes
all information about current portion, line, area, and column to the
callback, and checks the return from the callback, to decide if it needs
to continue iteration (in case when callback indicated that if doesn't
need further data), and if it needs calling the callback for the rest of
current portion's lines.
This allows to have the code that calculates and iterates dimensions of
lines in one central place, without the need to have duplicating logic
in several places.
One important exception is ImpEditEngine::Paint, which iterates without
ImpEditEngine::IterateLineAreas, because it does many atomic paint
operations in different points of iteration process, and implementing
ImpEditEngine::IterateLineAreas to call callback in the required places
would require increased complexity, which is left for a future change.
To make that possible, ImpEditEngine::IterFlag should be extended to
indicate additional requirements.
Note that in fact, ImpEditEngine::Paint was taken as the model for
implementation of ImpEditEngine::IterateLineAreas, with its detailed
handling of all the vertical offsets like additional line spacing and
interparagraph spacings that depend on context.
The notable result of the centralization of the iteration code is slight
change of heights reported by ImpEditEngine::CalcTextHeight. Previously
it simply added all pre-calculated heights of portions, and not taking
into account all the spacing handling that ImpEditEngine::Paint did,
which was inconsistent (calculated height was different from painted
height). Now ImpEditEngine::CalcTextHeight should provide more accurate
results, which required small changes in the unit tests.
Change-Id: I33cbb978deb974b314d36fda8674186a03991107
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116034
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: If03d2f7f22c65aaebe236d9b33e6609d31660387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116810
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I97ddde9659f337932b4165b794a769b83882126d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116802
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I71052f8db941733ab4e4b1b36cbf1fcb28eac9d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116420
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic1a1577ed837d3fa2b7b99474f4cee30300628f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116290
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
IPropertyArrayHelper & rInfo = getInfoHelper(); crashes when
CandleStickChartType is final for unknown reasons. I see this with
gcc-11.1.1-1.fc34.x86_64 in 7-1 locally but also in the fedora
libreoffice-7.0.6 built with gcc-10 so this isn't a recent problem.
#1 0x00007ffff6f4fe91 in cppu::OPropertySetHelper::getFastPropertyValue(int) (this=this@entry=0x5bdd588, nHandle=nHandle@entry=3) at cppuhelper/source/propshlp.cxx:549
#2 0x00007fffad45e9ff in chart::CandleStickChartType::getSupportedMandatoryRoles() (this=0x5bdd520) at chart2/source/model/template/CandleStickChartType.cxx:219
Change-Id: Ia029162587da1fc00df32866863deb186c7e11bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116196
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I7d1dc5d524a8a6f43f8371250d9e6f3c9c7a2589
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115995
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
and inherit ToggleButton from both it and Button
Change-Id: If0e500aca8d0ffa087cb5e2bfc1786372fbff4eb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115921
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
A new function was defined, XdataInterpreter::getChartTypeSpecificData.
Being 100% chart-type-agnostic when retrieving chart data is impossible;
candlestick charts can have different numbers of sequences per series,
and this information is not present in any other chart type.
Change-Id: I0f54b09202c42667331b083d54d90e4ceee81083
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113075
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4e06ac82108e5381cd11fbd6407e1ce1e85c3ac6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115822
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ic0a39b4cb6f7af6fbdd99fc93677a0c2d966234d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115671
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
|
|
as part of a longer-term goal of doing our
widget rendering only inside a top-level render-
context.
I moved all of the OutputDevice-related code that existed in vcl::Window
into a new subclass of OutputDevice called WindowOutputDevice.
Notes for further work
(*) not sure why we are getting an 1x1 surface in
SvpSalGraphics::releaseCairoContext, but to fix it I clamp
the size there
(*) might have to dump VCLXDevice, and move it's code down into VCLXWindow and VCLXVirtualDevice
(*) can we remove use of VCLXDevice in other places, in favour of just talking to the VCL code?
Change-Id: I105946377f5322677d6f7d0c1c23847178a720b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113204
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0249b18fd40f4f5ef95e2101286dc25782c42eb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115684
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
since we've got all the information from the beginning.
Change-Id: I4045c8fd5ab5653cd390ceb29cfef76bd6c520a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115587
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ief280ca4cb2cdadfc41f7c98bdec4044475c7daf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115588
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
since we've got all the information from the beginning.
Change-Id: I37098766967968f0db722c8998158d626792545e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115586
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
because it introduces a link-time dependency of vcl on toolkit,
and toolkit already depends on vcl
This reverts commit f7a86c5cdf4323c99d26512bf78de7f7c380667d.
Change-Id: Ibdd4f3e8221d70e2abd8fcbda67f85af3ac0396e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115547
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
No need to store two different pointers and hide the
underlying class behind an UNO interface
Change-Id: I72c55e912caa9eae1cffa6c9d1b1d480e5668d40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115496
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
after
commit 2ed8c34bca56c1a30d727b21d9096cb77e88197a
Date: Wed May 5 10:54:44 2021 +0200
use a single global item pool for chart2 draw model
Change-Id: I5f6b1b1917f60c9a8603b58368da8b34f174f7db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115478
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I645543fa27ca8b75b36ed7798f0af7b81fd09f49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115477
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
[clang-analyzer-core.uninitialized.UndefReturn,-warnings-as-errors]
Change-Id: Idfb848f343d9c71655848a32a19c03c0e6893b7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115265
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
so we can remove SfxItemPoolUser, which is a right
performance hog when we have large calc spreadsheets
Change-Id: I344002f536f6eead5cf98c6647dd1667fd9c8874
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115247
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
which exposed a bug in SvxUnoNameItemTable::replaceByName
Change-Id: If3207df6d46a2185b78ea5c3e1c145527b42d7cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115126
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If21defdf1b59219e3b81d803423713972412da7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115244
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
plugin code needed some updating because it was interacting badly with
PCH code in pluginhandler::ignoreLocation
Change-Id: I228f94a4e285747bd1d5b8536010f8617118cafa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115212
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7ff6aa4feeccd790b6176cb60b6adb9b21db0f63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115135
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
these defaulted to not visible before...
commit ec548bce309d965a25e807ae79432114926e06f3
Author: Caolán McNamara <caolanm@redhat.com>
Date: Mon Oct 15 11:14:02 2018 +0100
weld ChartTypeDialog and SchLayoutTabPage
Change-Id: I101c56b855d0bdc43559ca4561d298fa4ad92572
Reviewed-on: https://gerrit.libreoffice.org/61797
Change-Id: I424368e108726376140a0e83e085fe5ab01c497f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115129
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|