Age | Commit message (Collapse) | Author |
|
Now that the btlr writing mode works reasonably well in table cells, the
next context is shape text. But turns out that DOCX shape text lacked
support in the easier tbrl case, so add that first.
Also remove the char-level text rotation code in oox, that is
effectively dead code since we import drawingML shapes as shape +
Writer TextBox.
Change-Id: I30c7793221cc3aceedfcfd9e4e1725634ebb3309
Reviewed-on: https://gerrit.libreoffice.org/71329
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Icd00e2aaa5932564668cd12ce4ee63aecc34419a
Reviewed-on: https://gerrit.libreoffice.org/71226
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Regression from commit 59339dec1ce56213dc74a06af2f0d35ac1c534d7
(tdf#105150 PPTX import: try harder to handle <p:sp useBgFill="1">,
2017-01-06), the problem was that we gave a white solid fill to a shape
which is meant to be transparent.
Fix the problem by limiting the scope of the mentioned commit to solid
colors only, and also extend to code to look for background fill from
the masterpage as well. This allows not hardcoding the white solid fill
and leaves the fill style of shapes as transparent where the slide
background is a bitmap or other more complex fill type.
Change-Id: I0063e88d510250652d2b14856df3bd431681422d
Reviewed-on: https://gerrit.libreoffice.org/71107
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Drop FSEND_t: C-style varargs code was replaced since version 6.0 in commit
d43fc40718217d89cc95cc3c0bc0b8e7926abcc0, so it's time to remove the last bits.
Drop int-to-string macros that are simple wrappers over OString::number.
Avoid unnecessary string type conversions.
Change-Id: I86478577b8e469f99b5a90619e5f78a61f4f23fb
Reviewed-on: https://gerrit.libreoffice.org/70964
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Also fix tdf#123833 and tdf#123837.
In combined charts, now axis types are exported in the right order
(catAx[1], valAx[1], catAx[2], valAx[2]). The Y axes are exported
correctly with the correct axIDs of the chart types: the first one with
the primary axId, the second one with the secondary axId. X category
axis crosses the Y axis at the right place, all data series are attached
to the right Y axis, and the Y major grid doesn't disappear.
Note: don't export the CrossoverPosition/CrossoverValue, if the axis
is deleted and invisible, because MSO will show the secondary X axis,
even if the axis doesn't exist. The problem was the unnecessary export
of the axis with the default css::chart::ChartAxisPosition_END
CrossoverPosition value.
Change-Id: Id429e654ff0ba45b5f9db877b7c4dd6e65433408
Reviewed-on: https://gerrit.libreoffice.org/70814
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
Hyperlink inserted to chart lost after export.
chart_hyperlink.xlsx: Test file from Excel 2016.
Change-Id: Ideca10e544193ba43d7c2ef6e9dd8e393383edc1
Reviewed-on: https://gerrit.libreoffice.org/70648
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
* basing on provided conn alg params
* also moved setting arrow direction from getConnectorType() to algorithms
Change-Id: I76898a4ccad961edd389677c31e7d8c05bcdf5fe
Reviewed-on: https://gerrit.libreoffice.org/70598
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In combined charts, now X category axis crosses the Y axis at the right
place, all data series are attached to the right Y axis, and the
Y major grid isn't lost.
Note: Let's check which axis is attached to the first charttype
(in case of combined chart, the first one is a column chart) and create
that axis first. In OOXML standard, the first CT_valAx tag contains the
axID of the primary axis and the second CT_valAx tag contains the axID
of the secondary axis.
Change-Id: Ib123f95ec41ef5dbbf0599efd7a646f4640a9b70
Reviewed-on: https://gerrit.libreoffice.org/70464
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
to find stuff like
OUString s = OUString("xxx")
Change-Id: Ie7ed074c1ae012734c67a2a89c564c1900a4ab04
Reviewed-on: https://gerrit.libreoffice.org/70697
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
V522 There might be dereferencing of a potential null pointer.
Change-Id: Ie4bc74a734a6d5a73838a27e0d80cc8e51595839
Reviewed-on: https://gerrit.libreoffice.org/70730
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I59ef0a6da411b8af8bdf8d8efb1d733db7475d9c
Reviewed-on: https://gerrit.libreoffice.org/70707
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ia418fdf7077d1c0c169671770237381c4da7b7b0
Reviewed-on: https://gerrit.libreoffice.org/70582
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
connector arrows are now correctly positioned and rotated
Change-Id: I6407ec5e2d6e29d250f751f8dc5feae878d3c74c
Reviewed-on: https://gerrit.libreoffice.org/70525
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
so that it works on Windows as well
Change-Id: Ia919677067c90a2c9478e3666bfe50489996756f
Reviewed-on: https://gerrit.libreoffice.org/70599
Tested-by: Jenkins
Reviewed-by: Grzegorz Araminowicz <grzegorz.araminowicz@collabora.com>
|
|
now all transition arrows are created in cycle diagrams
Change-Id: I69e932f0060786b702dbecae72245bb624fa602b
Reviewed-on: https://gerrit.libreoffice.org/70457
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
XLSX import created a redundant series container for data series with the
same chart type, when they were attached to a different axis. Modifying
the loaded chart by the user, ie. attaching one of its data series to a
different axis resulted broken OOXML export later, because based on the
new axis, splitDataSeriesByAxis splitted the first or the redundant series
container further. Now the import creates only a single series container
for the series with the same chart type, preventing potential export problems.
Change-Id: If951feaca3cb3b5df7718e9d7bfd59620ef3c4d3
Reviewed-on: https://gerrit.libreoffice.org/70141
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
preserving SmartArt allows editing it in PowerPoint after saving as pptx file
* moved common parts for docx and pptx export to oox/drawingml
* fixed export tests that expected shapes on output
Change-Id: I3e70a9f4177bebf5e1671232f4cd0ef0e7212626
Reviewed-on: https://gerrit.libreoffice.org/69598
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I46d62ec8b7f5347fe7a69e6eb7ac0f1affcfd5b8
Reviewed-on: https://gerrit.libreoffice.org/70342
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: If025c21f3961372f861c8bb9df722fbdae5cc3cb
Reviewed-on: https://gerrit.libreoffice.org/70339
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Hyperlink inserted to image lost after export.
image_hyperlink.xlsx: Test file from Excel.
Change-Id: I8dc47528dafc8de5d1e01720697ef57f0ad9628d
Reviewed-on: https://gerrit.libreoffice.org/70248
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
The helper marco is used in export code to convert UTF-16 internal
string representation to UTF-8 used in XML encoding. I suppose that all
strings here should be already valid UTF-16 (an invalid input should
have been validated at import/input stage). An invalid string at this
stage means a programming error in another part of code that breaks this
precondition, and should not be handled at export stage.
(See also commit 0267a2326b5282023e8b08a147eca178c5db1980.)
This effectively changes flags used in conversion from UTF-16 to UTF-8,
so that now RTL_UNICODETOTEXT_FLAGS_INVALID_ERROR is used instead of
RTL_UNICODETOTEXT_FLAGS_INVALID_DEFAULT, so that the result would be
truncated on invalid bytes instead of inserting U+FFFD, and would fail
assertion in debug builds.
Other changed flags don't affect UTF-16-to-UTF-8 conversion.
Change-Id: I12b2cc5378208904c3266924187d6402700ed6f3
Reviewed-on: https://gerrit.libreoffice.org/69801
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
splitDataSeriesByAxis couldn't split series correctly into two
sequences, because it put all series into the first created sequence,
except the first series of the newer sequence.
Other improvement: first sequence of the return vector always
contains the series attached to the primary axis.
Change-Id: I6e107aa990f9a1a1db49cae2a4f3c9d8a35fb54c
Reviewed-on: https://gerrit.libreoffice.org/70059
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
|
|
V572 It is odd that the object which was created using 'new' operator
is immediately cast to another type.
Change-Id: I54976062dc3f62eaaa79f89eff54454f0b24ac2c
Reviewed-on: https://gerrit.libreoffice.org/69989
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I31b12fa3f80dc450fff27128efb2fbebc711b249
Reviewed-on: https://gerrit.libreoffice.org/69859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I2aa9a8f14b6db2098931a14c6eed522a9d2653ed
Reviewed-on: https://gerrit.libreoffice.org/69682
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I444cb71bc3d045072a4b1f9eed279ed7e425a0d4
Reviewed-on: https://gerrit.libreoffice.org/69481
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
look for places we are doing code like:
Reference<XProperty>(model, css::uno::UNO_QUERY)->getAsProperty()
which might result in a SIGSEGV is the query fails
Change-Id: I5cbdbc9e64bd0bed588297c512bf60cbacb9442e
Reviewed-on: https://gerrit.libreoffice.org/69044
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
p:tn (see below) were treated as delay value instead of timenode id.
<p:stCondLst>
<p:cond evt="begin" delay="0">
<p:tn val="5"/>
</p:cond>
</p:stCondLst>
Just convert the timenode id to XAnimationNode and set
the event source properly.
Change-Id: Ib408be6714c6ac70dad7018e544e560cf59a40c0
Reviewed-on: https://gerrit.libreoffice.org/69340
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
Only copy string for SAL_WARN call, to not print unneeded information
Change-Id: I962ac8a7ed9bc8ee08d1ea31f4f13a0670cbdf3a
Reviewed-on: https://gerrit.libreoffice.org/69232
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
Change-Id: I75dbafe00609c6f85ec7cc0cca492bc01cb62052
Reviewed-on: https://gerrit.libreoffice.org/69231
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
of MSO 2007/2010 documents with "automatic" chart area
formatting, setting also the default 0.75 pt border width
and light gray border color.
Note: MSO 2007/2010 and MSO 2013/2016 have different
"automatic" border colors. This fix uses the last, light
gray version instead of the dark one.
Change-Id: I579f3745d5fcb2a36e1b4d519320631d20e60fd4
Reviewed-on: https://gerrit.libreoffice.org/69341
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ieaf341dd13e06046044f3523c3aad74476160402
Reviewed-on: https://gerrit.libreoffice.org/69328
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
before that there were imported two GroupShapes:
- empty one with properties like id, name, InteropGrapBag
- second one with actual shapes
also fixed tests that relyed on that behaviour
Change-Id: I2b94a53e21666b16725c4353448d75e916e4f9df
Reviewed-on: https://gerrit.libreoffice.org/69252
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
DispBlanksAs=gap mode of OOXML is different from
treat-empty-cells=leave-gap mode of OpenDocument,
because formulas with no numerical values and
strings are no gaps in OOXML line charts, but zeroes.
When the data source of the line charts contains
formulas with no numerical values or strings,
but it doesn't contain empty cells, as a workaround,
the charts will be imported with the
treat-empty-cells=use-zero setting to get the same
line chart as in MSO.
Note: now result of ScChart2DataSequence::getData(),
a sequence of Any values contains UNO void values for
empty cells instead empty strings, allowing the
distinction of the empty cells and cells with empty
string values.
Change-Id: If9a101d66b5b750051928fa7b10b05cea6040071
Reviewed-on: https://gerrit.libreoffice.org/69054
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
it will allow to preserve SmartArt when saving PPTX files
Change-Id: I9bb66c59d202b4ce426864599014d042d4aa04b0
Reviewed-on: https://gerrit.libreoffice.org/68916
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Idd125c18bee1a39b9ea8cc4f8c55cddfd37c33e1
Reviewed-on: https://gerrit.libreoffice.org/68579
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Third token (i.e. day) would span to the end of the string
and conversion to int works just because it stops at first
non-numeric character.
Change-Id: I4f608aafadd634c312f7cfd986966f453bfca872
Reviewed-on: https://gerrit.libreoffice.org/68121
Tested-by: Jenkins
Reviewed-by: Matteo Casalin <matteo.casalin@yahoo.com>
|
|
This reverts commit c9bb48386bad7d2a40e6958883328145ae439cad,
and adds a bunch more fixes.
Change-Id: Ib584d302a73125528eba85fa1e722cb6fc41538a
Reviewed-on: https://gerrit.libreoffice.org/68680
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This reverts commit 9865440d217d975206a3f91612f0666312bc8fd8.
This is not ready to land yet, seems like the latest update
of the logic reveals a bunch more places I need to fix before it can land.
|
|
verify that parameters use the exact same typedef-names (if any)
in definition and declaration
Change-Id: I55d2817f599b0253904dce2d35a1a93967e15a77
Reviewed-on: https://gerrit.libreoffice.org/68439
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Once the constraints determine the size, the aspect ratio may shrink one
dimension to achieve the requested ratio. Implement the case where a >1
ratio shrinks the width, so the container of the image-text shape pair
has correct aspect ratio.
Change-Id: I7bac764c031e80bac532c4f97ebd5b5096401096
Reviewed-on: https://gerrit.libreoffice.org/68510
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Shape text has two kind of spacing inside the shape's bounding box: the
shape-level margin and the paragraph-level one. Only the second was
handled in the tx algorithm so far, add support for the first.
The margins taken from constraints were way large by default: the only
explanation I found for that is that SmartArt layout sometimes
calculates in MMs, sometimes in Points, and the ratio between the two is
exactly the Impress / PowerPoint margin. So assume that indeed that unit
difference is the reason for the smaller in-PowerPoint margin values and
do the same on our side.
Change-Id: I6f1e54301e2e9b33a7e721be34244d968cccf42d
Reviewed-on: https://gerrit.libreoffice.org/68453
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
fields private
Change-Id: Id3c6b123f06ab5dcf87628de4c347626110d2d27
Reviewed-on: https://gerrit.libreoffice.org/68302
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The snake algorithm in PowerPoint seem to interpret spacing as follows:
if you have N elements, then there should be the requested amount of
spacing between the elements, and also double amount of spacing around
the actual list of elements.
With this, the SmartArt and the title shape in the bugdoc no longer
overlaps.
Change-Id: I5d6885b434bfaff9de9aac595a298a5346524e19
Reviewed-on: https://gerrit.libreoffice.org/68397
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The bugdoc has 3 items in the picture strip and PowerPoint laid this out
as a single column with 3 rows (as a snake algorithm). We used to put
the first two items to the first row and the third item to the second
row.
Improve out layout by taking into account what aspect ratio the child
algorithms request: this way it's obvious that we should use a single
column in case we have a large enough aspect ratio and few enough items.
(PowerPoint also uses multiple columns without the aspect ratio
request.)
Change-Id: I9f1158c04c665fc6a2c85e4ac3a1ed363b1c75fb
Reviewed-on: https://gerrit.libreoffice.org/68370
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
The aspect ratio request of the Shape is not yet used in
AlgAtom::layoutShape(), though.
The heavy-lifting is needed, because the number of cols/rows in the
snake algorithm depends on the aspect ratio request from the child
algorithm, so need to transfer the aspect ratio from child algorithm ->
layout node -> shape -> parent algorithm.
Still no functional changes intended.
Change-Id: I8cbe53cfac0965ab5d8c05f75fe27e819de6836a
Reviewed-on: https://gerrit.libreoffice.org/68354
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
No functional changes intended.
Change-Id: I847f725a5ecf516755a4b6d85e3180979520eee2
Reviewed-on: https://gerrit.libreoffice.org/68344
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Handle timenode condition properly. Begin and End of
TimenodeContainer allow Sequence, Event, Timing, double,
and VOID. Only events with Source set are valid.
Change-Id: I25519110715072ca36b7f5c55c26415f9fbe9deb
Reviewed-on: https://gerrit.libreoffice.org/68210
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
Change-Id: I31d0e6c3559af2e322fb474b97f3bbf4d5064831
Reviewed-on: https://gerrit.libreoffice.org/68280
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
presProps stream handler is added to do this.
Export is not handled here.
Change-Id: I1979941a09c472c14f96c778ca9960ec14786fbe
Reviewed-on: https://gerrit.libreoffice.org/68237
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|