Age | Commit message (Collapse) | Author |
|
Change-Id: Iee1e16c516547e8f23631b33c928ac6637050f68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124376
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I987c56feab147cdbeb4ad58bd5ebb23dce6dbbca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124215
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
> oox/qa/unit/drawingml.cxx:162:testPresetAdjustValue::TestBody
> equality assertion failed
> - Expected: 1
> - Actual : 0
Change-Id: I3ff0707db485dce1e43c14b8d1a5828da8e14923
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124139
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I3b4226a9d089ec9aedab95d96e50a068f57a76c7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123991
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Hyperlinks on the shapes of a group shape weren't imported.
Now all of them are imported correctly.
Change-Id: Ic42892650a3492958600232bd7038585f9aa6ae1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123127
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
PowerPoint aligns the bottom of the text to the path for prstTxWarp
'textCircle'. That preset type is mapped to 'fontwork-circle-curve'
on import with additional attribute ScaleX=true. Currently the property
TextVerticalAlign is only evaluated in case ScaleX=true. Therefore I
have written the condition similar as the already existing with
'fontwork-arch-up-curve'. If it will be necessary later, all those
conditions can be changed to use rPresetType instead of rClass.
The rendering is slightly different compared to PowerPoint, because
descenders and paragraphs line-spacing are handled differently.
The rendering has still the problem, that in PowerPoint the letters
are placed without gap, but in LO they have additional distances from
each other. The needed ODF attribute draw:text-path-mode is not yet
implemented in LO. Its value 'normal' would be needed here.
Change-Id: I1f03d4845312885eff9ee8dbe1d51ddd437ed8e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123726
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Change-Id: I1d7cfd157d56a501be4497e6f4e94f3f33429139
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123689
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I780ffee680e52c240a1bd212f34c9c019c8b5e59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123625
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
... to avoid hidden cost of multiple COW checks, because they
call getArray() internally.
This obsoletes [loplugin:sequenceloop].
Also rename toNonConstRange to asNonConstRange, to reflect that
the result is a view of the sequence, not an independent object.
TODO: also drop non-const operator[], but introduce operator[]
in SequenceRange.
Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The scenarios are:
1. Calling sequence's begin() and end() in pairs to pass to algorithms
(both calls use getArray(), which does the COW checks)
2. In addition to #1, calling end() again when checking result of find
algorithms, and/or begin() to calculate result's distance
3. Using non-const sequences in range-based for loops, which internally
do #1
4. Assigning sequence to another sequence variable, and then modifying
one of them
In many cases, the sequences could be made const, or treated as const
for the purposes of the algorithms (using std::as_const, std::cbegin,
and std::cend). Where algorithm modifies the sequence, it was changed
to only call getArray() once. For that, css::uno::toNonConstRange was
introduced, which returns a struct (sublclass of std::pair) with two
iterators [begin, end], that are calculated using one call to begin()
and one call to getLength().
To handle #4, css::uno::Sequence::swap was introduced, that swaps the
internal pointer to uno_Sequence. So when a local Sequence variable
should be assigned to another variable, and the latter will be modified
further, it's now possible to use swap instead, so the two sequences
are kept independent.
The modified places were found by temporarily removing non-const end().
Change-Id: I8fe2787f200eecb70744e8b77fbdf7a49653f628
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123542
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
like table layout of MSO does, e.g. 20 pt to 19.5 pt.
Changing table row height is only for interoperability.
To avoid of regressions, apply this workaround only for
documents created in MSO.
Note: likely this is an old adjustment for low-resolution
monitors, where 0.75 is the factor between 96 ppi of Windows
resolution and (originally) 72 ppi of monitor resolutions.
Co-authored-by: Tibor Nagy (NISZ)
Change-Id: Ie1e2c781d21174a877b18cd3250eb445222bd1c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122428
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Follow-up to commit 9bb91441b46d677860530d8bf9597c96561a1b0a
"tdf#141704 PPTX import: fix hyperlinks on images"
Change-Id: If29241ea06253e503dae27f8dc762574a5a634de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122717
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The passwords for editing in PPTX documents
created with PowerPoint weren't asked and verified.
Change-Id: I62eb4fd68aac6422c1221a639f4815459ab556c9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123130
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Icd4f4980332edc3fd9027cc4cace2b4a0d0c1315
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123234
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I15d56d133cf464a3cb6483be785b1259c7f35b43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123120
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...compared to a full-blown O[U]String, for temporary objects holding an
O[U]StringConcat result that can then be used as a std::[u16]string_view.
It's instructive to see how some invocations of operator ==, operator !=, and
O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit
materialization of an O[U]String temporary, and how that expensive operation has
now been made explicit with the explicit O[U]StringConcatenation ctor.
(The additional operator == and operator != overloads are necessary because the
overloads taking two std::[u16]string_view parameters wouldn't even be found
here with ADL. And the OUString-related ones would cause ambiguities in at
least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with
RTL_STRING_UNITTEST, so have simply been disabled for that special test-code
case.)
Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Follow-up to commit 6e200689eb309cdbe1e4f08311a400835de19bfb
"tdf#141704 PPTX import: fix hyperlinks on images"
Change-Id: Ie9f1ba56d03462bb8d7ab376e23c89c921a8bcd6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122610
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I4c0002e72703eded435bfe4985f5b0121bf8524b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122843
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I have moved the header file to include/vcl/rendercontext as this will
eventually be part of the RenderContext split from OutputDevice.
State and associated enums have also been moved to the vcl namespace. I
have also moved ComplexTextLayoutFlags into the vcl::text namespace.
Change-Id: I0abbf560e75b45a272854b267e948c240cd69091
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121524
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Note: see "Interaction..." in the local menu of the image
of the first slide for manual checking of the fix.
See commit 9bb91441b46d677860530d8bf9597c96561a1b0a
"tdf#141704 PPTX import: fix hyperlinks on images"
Change-Id: Iba372c095f76b263575d261a7a0fc98eda449bce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122429
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I02b4352f02fe32f40c4fe0ab198d8ac094381c7a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122491
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
When exporting custom shape arrows LO used to fall back to writing
out their plain vertex coordinates, losing the customizability of
the shape after loading from file. This commit changes the export
of some of the most commonly used arrow custom shapes to proper
adjustment value export.
Follow-up to commit 63cd67e5e18f01aca303131e148c80398a181a41
"tdf#92525 tdf#142398: fix export of simple custom shapes".
Change-Id: If248556764bdb7e00cfde4ebe5b32bb380b1fa19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121901
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Reading 'rectA.IsInside( rectB )' kind of suggests that the code
checks whether 'rectA is inside rectB', but it's actually the other
way around. Rename IsInside() -> Contains(), IsOver() -> Overlaps(),
which should make it clear which way the logic goes.
Change-Id: I9347450fe7dc34c96df6d636a4e3e660de1801ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122271
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
...to avoid construction of temporary O(U)Strings, in anticipation of using
C++17 std::from_chars once that is available in all our baselines, similar to
99a1290b3f2c8584db0a33fe48adf93dccce3a92 "Use existing rtl_math_stringToDouble"
Change-Id: Ib92504341c3ae9dd599f91725b0af5b7219a201d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The passwords for editing in XLSX documents
created with Excel weren't asked and verified.
Note: LibreOffice supports only a subset of the hashing
algorithms specified in MS-OE376, according to
DocPasswordHelper::GetOoxHashAsVector() and
https://docs.microsoft.com/en-us/openspecs/office_standards/ms-oe376/f70a4140-340b-4e94-a604-dff25b9846b1.
Also the documents encrypted with unsupported algorithms
got edit protection now, but it's not possible to add
permission to edit them (copy of these documents are still
editable).
Change-Id: Iabc90f6bba4ed071dd2c60e9dea905481816964b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121497
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I9b35d6333afa6b305bf73fc55a7e60c8365674e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122134
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The header got some changes:
1. Move UnoTunnelIdInit and isUnoTunnelId into 'comphelper' namespace
2. Rename UnoTunnelIdInit to UnoIdInit, as a precondition to replace
of uses of OImplementationId with it, including in XTypeProvider
3. Introduce convenience functions 'getSomething_cast' to cast between
sal_Int64 and object pointers uniformly.
4. Rename getUnoTunnelImplementation to getFromUnoTunnel, both to make
it a bit shorter, and to reflect its function better. Templatize it
to take also css::uno::Any for convenience.
5. Introduce getSomethingImpl, inspired by sw::UnoTunnelImpl; allow it
handle cases both with and without fallback to parent.
6. Adjust UNO3_GETIMPLEMENTATION_* macros
TODO (in separate commits):
- Drop sw::UnoTunnelImpl and sw::UnoTunnelGetImplementation
- Replace all uses of OImplementationId in core with UnoIdInit
- Deprecate OImplementationId in <cppuhelper/typeprovider.hxx>
- Change implementations of getSomething to use getSomethingImpl
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: If4a3cb024130f1f552f988f0479589da1cd066e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122022
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Hyperlinks on images pointing to the "first/last/
previous/next" slides and "exit presentation/go to
the website/go to the slide" weren't imported.
Note: images added via the Content placeholder
will be fixed later.
Change-Id: Idda1ff6fd3243b06262637c7c8e579e78309e317
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121369
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Excessive padding in 'struct chart::TickInfo' (11 padding bytes, where 3
is optimal).
Excessive padding in 'class EscherBlibEntry' (10 padding bytes, where 2
is optimal).
Excessive padding in 'struct oox::drawingml::ConditionAttr' (8 padding
bytes, where 0 is optimal).
Excessive padding in 'struct oox::drawingml::Constraint' (12 padding
bytes, where 4 is optimal).
Excessive padding in 'struct (anonymous namespace)::Number' (10 padding
bytes, where 2 is optimal).
Change-Id: If7573afa8a794497c9a2bf1c7c15e8f11ff11407
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121993
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: If3c623f04cd912ea419bb720178553a43cb713e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121933
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Usually hyperlinks are processed by TextBodyContext, but
for grouped shape we accidentaly gone into TextParagraphContext
It has almost all possibilities to process txbxContent,
but not hyperlinks.
Additionally some hyperlink char attributes (color and underline)
can expand to follow up ordinal text. Additional small hack applied
to avoid this.
Unfortunately this is not a final solution: such document fails
roundtrip and hyperlinks are lost after saving to DOCX.
Change-Id: Ie954f53696bd872cb1f59cb586fb55f6cd7c73bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121172
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
where we are just provide checking for a following static_cast.
I'd rather have an explicit assert failure than a random crash
Change-Id: Iab6c6b056341018deaa74b78b075e564f72c58d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121814
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Before this fix, date categories imported in oox's DataSourceContext were
stored as formatted strings according to number format code in <c:formatCode>
under the <c:cat> tree. As a result chart2 could not recognize them
as dates. This causes problems like:
* The axis that is linked to date categories cannot use the
scaling/range-selection(min/max)/increments specs mentioned as axis
properties. This results in distorted/unreadable chart renders w.r.t
the date axis.
* No re-formatting is attempted as per the number format provided for axis.
This patch introduces a role qualifer argument to the XDataProvider
interface method createDataSequenceByValueArray to support categories of
date type via this method.
When exporting to oox, write date categories and format code under
<c:cat>
<c:numRef>
<c:numCache>
This patch also fixes some discrepancies in date axis interval
computation (auto mode) found by already existing unit tests.
Change-Id: Ibc53b0a56fdddba80ba452d5567ce98d80460ea7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121525
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
tdf#143127: Add officeRel namespace to XML_userShapes
to fix invalid file error in MSO.
tdf#143130: Add mbUserShapes variable to ShapeExport class
to fix export of embedded shapes of charts in DOCX.
Change-Id: I10c1dbf905af96d6a63a9243514b32a6440e63f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121035
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I78339f1df1f0c55c7edaa552940b07d1ada3aeb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121386
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When <c15:showDataLabelsRange> boolean flag is present, the imported
label texts are added as the first text field in oox data label model.
The cell-range associated is also preserved. The export part preserves
the how labels were store originally in <c15:datalabelsRange>.
However in order to make the custom labels reflect the contents of the
cells in the associated cell-range, more work needs to be done. For this
the labels present in <c15:datalabelsRange> needs to be made available
as a data-sequence with a new "role" like "point-labels" in
XInternalDataProvider implementation and and make the label renderer
read this data source rather than consulting the custom label fields
property which is static after import.
Change-Id: Ibc7045fa5ea209d463680c96efb49a06662d2500
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121313
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(i.e. centered title) similar to <p:ph type="title"/>.
See commit 7eb0e52527e729a21973e70d5be8e0a6779ec748
"tdf#142648 PPTX: import long slide names to avoid broken link export",
commit 253bee65bc24d999c3629a4d503d0fa01b355cfc
"tdf#142646 PPTX import: count repeating slide names" etc.
Change-Id: I5f25f04f23981ce2ff64dc792fe8464682d749a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121295
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The points in file source might have units. Decode was missing.
maWidth and maHeight are used in ShapeBase::convertAndInsert(), and
moCoordSize is used in PolyLineShape::implConvertAndInsert(). So
ShapeContext needs to provide both in case of importing a polyline.
That was missing.
Word writes the size into the coordsize attribute of the v:polyline
element. But from VML specification it need not exist, but bounding
rectangle of points has to be used. That is added too.
Unclosed polyline cannot be filled in LO and ODF, a fill is only
possible for a closed polygon. LO defines a sequence of points as
being closed, if first point == last point. The import is adapted
to that behavior.
Word allows an unclosed polyline to have filling. That cannot be
represented with a simple PolyPolygonShape but would need a
CustomShape. Because the user cannot yet edit points in a CustomShape
but can do that in a PolyPolygonShape, the v:polyline element is
not converted to a CustomShape on import and not to DML on export.
LO would first need an UI for editing points of a CustomShape.
Change-Id: I23d08fda2005f8b36488e1d9ba32e565d8a0f803
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121042
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Regression from commit 9bd99c08e8662becdd5ac8b47ef6f953c14e65fc
(CWS-TOOLING: integrate CWS os128, 2009-06-03), the problem was that the
SvxItemPropertySet was both used to store a property map (information
about UNO properties) and also as a descriptor for a not yet inserted
shape.
The above commit improved performance by sharing a single instance of an
SvxItemPropertySet for the same shape types: this works for the property
map, but doing the same for property values is problematic.
In practice, this eliminates the need for a workaround in oox/, the
user-visible problem was that loading a document with smartart, then
loading a document with group shapes (but without smartart) and saving
it would copy information from the first, closed document (!) to the
second document.
Just removing the oox/ workaround would make
make -C oox -sr CppunitTest_oox_drawingml CPPUNIT_TEST_NAME="testGroupShapeSmartArt testTdf131082"
fail, unsharing the descriptor piece makes it pass again.
Change-Id: Icdff2108ad0da18ce0ade081b1938dd74bc0ae90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120996
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I73191e5ab25fdd9fd8a788db9858b5eb9d3ab955
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120885
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
...seen at <https://ci.libreoffice.org/job/lo_ubsan/2113/> with recently-
introduced sw/qa/core/data/ooxml/fail/ofz37458-1.docx during
CppunitTest_sw_filters_test,
> /oox/source/vml/vmlformatting.cxx:202:38: runtime error: 6.40969e+23 is outside the range of representable values of type 'long'
> #0 0x2b40e7a68a1e in oox::vml::ConversionHelper::decodeMeasureToEmu(oox::GraphicHelper const&, rtl::OUString const&, int, bool, bool) /oox/source/vml/vmlformatting.cxx:202:38
> #1 0x2b40e7a68cf1 in oox::vml::ConversionHelper::decodeMeasureToHmm(oox::GraphicHelper const&, rtl::OUString const&, int, bool, bool) /oox/source/vml/vmlformatting.cxx:208:47
> #2 0x2b40e7bc3bb7 in oox::vml::TextBoxContext::TextBoxContext(oox::core::ContextHandler2Helper const&, oox::vml::TextBox&, oox::AttributeList const&, oox::GraphicHelper const&) /oox/source/vml/vmltextboxcontext.cxx:190:39
> #3 0x2b40e7b3190f in oox::vml::ShapeContext::onCreateContext(int, oox::AttributeList const&) /oox/source/vml/vmlshapecontext.cxx:526:24
> #4 0x2b40e7b34ee9 in oox::vml::RectangleShapeContext::onCreateContext(int, oox::AttributeList const&) /oox/source/vml/vmlshapecontext.cxx:639:26
> #5 0x2b40e7b34f42 in non-virtual thunk to oox::vml::RectangleShapeContext::onCreateContext(int, oox::AttributeList const&) /oox/source/vml/vmlshapecontext.cxx
> #6 0x2b40e5fdae26 in oox::core::ContextHandler2Helper::implCreateChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /oox/source/core/contexthandler2.cxx:100:34
> #7 0x2b40e5fddffb in oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /oox/source/core/contexthandler2.cxx:204:12
> #8 0x2b40e5fdfb32 in non-virtual thunk to oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /oox/source/core/contexthandler2.cxx
> #9 0x2b40fe645540 in writerfilter::ooxml::OOXMLFastContextHandlerWrapper::lcl_createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:2006:38
> #10 0x2b40fe60a6a4 in writerfilter::ooxml::OOXMLFastContextHandler::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:254:21
> #11 0x2b40fe60a942 in non-virtual thunk to writerfilter::ooxml::OOXMLFastContextHandler::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) /writerfilter/source/ooxml/OOXMLFastContextHandler.cxx
> #12 0x2b40ca28e9de in (anonymous namespace)::Entity::startElement((anonymous namespace)::Event const*) /sax/source/fastparser/fastparser.cxx:465:44
> #13 0x2b40ca2899ed in sax_fastparser::FastSaxParserImpl::callbackStartElement(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, unsigned char const**) /sax/source/fastparser/fastparser.cxx:1306:21
Apparently lacking a general concept to report failure for too-large input
values here, just silently do a saturating conversation, as seems to be the
general approach for this kind of filter code.
Change-Id: I4511a5dd63bdbc973d60a521bd3aef445dea3fb1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120941
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Set PROP_CrossoverPosition value regardless of the mrModel.mbAuto
value, which is a different thing. This element specifies that
this axis is a date or text axis based on the data that is used for
the axis labels, not a specific choice.
Change-Id: Ifa291aac2f4bb3981d968de3489b23f1af485104
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120592
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ia89059eea51ca396a7c74143625ac9a6706de198
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120773
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I786096b989daa6004a6527aafbe825b6f0a22d90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120710
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I45243c6312545d51409574447e27f5320d4da79c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120493
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Change-Id: I0d233878ee49fcdc1338ec3bd700e5482d558163
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120694
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Ic7410f836e584df45101e78e345c8b3c8d355e09
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120680
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4f01eb3842ef198f02af274f54afb2760c820a4b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120655
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I4ca3a3a7ced1dac90ae896cc8a0abb08f830744e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120551
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
The change allowed to simplify many places where previously this API was
used, to avoid inefficient calculations (e.g., moving rectangle keeping
its size, and then immediately changing the size).
Change-Id: Ica2dc594d91cae83e2c2740c1f4fb23f44998916
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120461
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|