Age | Commit message (Collapse) | Author |
|
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109658
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
(cherry picked from commit 2c96bd26ec488d865370fe9d394e7c4e228e05ab)
Change-Id: I33ced8d667e37b7fb79f4c87b689f45966ac0097
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109739
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
|
|
The bugdoc had this constraint:
<dgm:constr type="l" for="ch" forName="text" refType="r" refFor="ch" refForName="img"/>
While img has no "r", it has:
<dgm:constr type="w" for="ch" forName="img" refType="w" refFor="ch" refForName="box" fact="0.2"/>
<dgm:constr type="l" for="ch" forName="img" refType="h" refFor="ch" refForName="box" fact="0.1"/>
Which is enough to fix the x position of the text to not overlap with
img.
(cherry picked from commit 1359e8c566970fcef860f7ba7f54a07d8e6e0513)
Change-Id: I80db290bd1695884ffb7b1eabaffa09462e8883d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109703
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(cherry picked from commit 2d582244680e7f6dec6e4a466e276f93ccb01dc9)
Change-Id: I6560756eb63856a22b43e3e65a7b7843cd2d5376
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109702
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
AlgAtom::layoutShape() is more or less the single function where all
layouting happens for all algoritms. Extract the pyra algorithm part
from it to a separate PyraAlg::layoutShapeChildren() before that
function grows too large.
(cherry picked from commit 318438a680e6bf5c2c592d5e997f6f45a4ae8e5f)
Change-Id: I097ac9ed6110536bbeb8a26ab35a8ee8a79d5b33
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109701
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Now with my GraphicFilter::MakeGraphicsAvailableThreaded() patches
for Impress images will be loaded in parallel as they are needed,
which should usually be more efficient than loading all of them
immediately.
This basically reverts commits:
b1319842a49cdf6512bbd9e81081e2a9edbd6089
04e27df3c162f1df02f061b94434a38d1eaa3a46
9eb8e2737d3a4d52ce1b0cc44091a3b7ecf59e3b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107945
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
(cherry picked from commit afa3dff9c7b963f1d312ef8c2efcbc8ab7271e62)
Change-Id: I46bb0d6d93fb69f03f464308f6fce1603aafdfd8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109393
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Regression from commit 14a56533ff2c9c859d22cd3039ada75b99e94bc0
(SmartArt Pyramid: Now lays out shapes, 2018-07-10), the added pyramid
algorithm by first centering the topmost children, then decrementing the
horizontal postion of each additional shape, with the end goal of having
0 horizontal position of the last children.
This means that simply avoiding the division in the 1-child case leads
to correct results, because in this case the only child is also the last
child at the sane time.
(cherry picked from commit f2e04fe98e313cffa3f98d55eae641415142a431)
Change-Id: Ifd0027e9616b0909dbfde43e1555427b50de4dad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109223
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Regression from commit 0024c48b4822062995effed7db4f1281196384bb (oox
smartart: consider rules when scaling in linear layout, 2020-07-31), the
problem is that I only tested horizontal layouts and this is not working
for vertical layouts.
Just disable the vertical case for now, to avoid unwanted side effects.
(cherry picked from commit c719db99166a7b4770855a9599ec65c70cd256c5)
Change-Id: I31a894157996a2371b8d0ec482ee91dc4d5b053e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109222
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
AlgAtom::layoutShape() is more or less the single function where all
layouting happens for all algoritms. Extract the snake algorithm part
from it to a separate SnakeAlg::layoutShapeChildren() before that
function grows too large.
(cherry picked from commit 99e51aaf2ad216888622a46a625479e1b42946d4)
Conflicts:
oox/source/drawingml/diagram/diagramlayoutatoms.cxx
Change-Id: I5e5ae66d16770fa72db6edf5df4cbd2ef3eea9c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109221
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Most of these are calls to
DocumentDigitalSignatures::createWithVersion(), where it doesn't make
a
difference if "1.2" or "1.3" is passed in but maybe it will be
different
with "1.4".
There is another ctor createDefault() which looks appropriate for
non-ODF contexts and can also be used when no actual signing or
verifying is done.
In cases where there's an actual document its Storage has the version.
Change-Id: Id636bbf965d9f96c7ed5f50774c509032525b2b1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93091
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Custom shapes export shadow as part of WriteShapeEffects(), so use the
same for table shapes as well.
This needs fixing the effect export up a bit, because table shapes have
no interop grab-bag, glow or soft edge properties, but the rest of the
code can be shared.
(cherry picked from commit 252cdd5f43d65095543e317d37e1a0ea4fd839e0)
Conflicts:
oox/source/export/drawingml.cxx
Change-Id: Icf0b90c5b44e3d9c4115c9f3b0d56ba0852ab640
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107881
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
PPTX export and ODP filter is still missing.
(cherry picked from commit b273e82aaa916b0f6198097dc32740faced73741)
Change-Id: I451b334ada80d9d228b7d7f36b5f26473b575ef6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107595
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
I plan to use this from oox/source/drawingml/table/tablecontext.cxx for
tdf#129961.
(cherry picked from commit f2e1685e489c054ea10afc0df52451c74da10cc0)
Conflicts:
solenv/clang-format/excludelist
Change-Id: Id5177467341f9ddf73c6043796ad35e9cc655d37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107592
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
because InternalDataProvider can not handle different category names
on the primary and secondary category axis.
Revert e0b0502516a10181bbd1737b93b38b2bba4c98e8 commit, except
the relevant unit test.
Regression from commit: e0b0502516a10181bbd1737b93b38b2bba4c98e8
(tdf#128016 Chart OOXML Import: fix duplicated category labels)
Also fix tdf#129994 (FILEOPEN - hang at import time), which is a
a regression from commit fa0a981af41a2606541eec1cb20a379a739691e0
(tdf#114166 DOCX chart import: fix missing complex categories)
Change-Id: I5d049e760eb1a647ea774be264349a2f16f15f5b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102463
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103617
Tested-by: Jenkins
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106084
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Text3DProperties is added to distinguish shape and text 3D effects.
Before there was implementation error about text camera z rotation
support. We were using shape effects for text. We already have not
support shape 3D rotation but we have text camera z rotation. This
patch includes import and export filter changes about text camera z
rotation.
Change-Id: I623392b82edf4585888d2f15ad91ffb2109d8f96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106033
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106047
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Change-Id: I166d547cdc01853fd81436c6cdc8d64b0fe817be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105618
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105912
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Export code has written for case that we have normal
rotation angle and camera z rotation together. If object
has not normal rotation but have camera z rotation, problem occurs.
Camera z rotation info is already exist between <scene3d> tags. If we
have not <xfrm rot="..."> (normal rotation angle) we shouldn't add camera
rotation here.
Change-Id: I1819953c937783d30b6e7ced978758300bb56d7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105341
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105350
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Instead of implementing proper OOXML 3D rotation (which would be
an entirely new feature if I understand correctly), I merely
interpret attribute "rev" of the rotation element a:camera/a:rot
as a directive to rotate the entire shape the usual 2D way. That
is already implemented and works well. This isn't the same thing
Word does, but it might be good enough for now. This is kind of a
mock solution, but it will be very easy to revert if it turns out
to cause problems.
Note: the export worked well previously, too (moreover, reloading
the first LO export fixed the import).
Change-Id: I2a99c119880bbed1c5b6430c4638cfbd10b7ac06
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103627
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit a9c5c0d814a266096483572b84c72875ef8efd77)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105352
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
|
|
Regression from commit 10bb02efd8afd42e633e370480104e2575546d8e
(tdf#129685 PPTX import: fix unexpected centering of shape text,
2020-09-18), now the problem was that some text should be left aligned,
but was centered.
Fix the problem by reverting most of the above commit: XML changes,
changes to SdImportTest::testTdf113198() (manual testing show that this
change is not needed after all) and changes to the
TextBodyPropertiesContext ctor in oox/ (but not the testcase itself).
Fix tdf#113198 again, this time in Shape::createAndInsert(), which is
meant to be closer to what the binary PPT import does.
With this, all cases from tdf#104722, tdf#113198, tdf#129685 and
tdf#137023 are meant to be handled correctly at the same time.
(cherry picked from commit dfa1856cdb4c69985ef1e809d33055427b6fbd76)
Change-Id: Id785252c26fc407cd74c9cfb55624091798d7773
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104050
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
1) When applying double outside spacing, introduced with commit
0a29c928afa74123bca05dc089c751603d368467 (oox smartart, picture strip:
fix lack of spacing around the picture list, 2019-02-26), make sure that
is only applied in the direction of a signle row: i.e. the bugdoc case
is left/right outer spacing, but no top/bottom spacing.
2) If a child shape has an aspect ratio request, make sure that it only
decreases what would be allocated by default, so the children never
leave the parent's rectangle.
3) Fix a mis-match between the first and second row, the unexpected
small left padding in the second row was because code assumed that all
child shapes have the same width; which is not true, when widths come
from constraints.
With this in place, we finally do a good rendering of the bugdoc, and
child shapes are always within the bounds of the background.
(cherry picked from commit 71303c5c23bdb385e9f12c0dbe5d2a0818b836ec)
Change-Id: Ia2606dcd945402f7dfe17c6e2f261bfd98667022
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103703
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This requires tracking what is the total of the width request of child
shapes, then scaling them according to what is the total available
width.
Additionally, the height of child shapes should be adjusted based on
their aspect ratio requests. A related trap is when an (invisible)
spacing shape is at the end of the row, that would result in smaller
spacing between the rows, so track the max height of shapes inside a
single row.
With this, finally the 6 child shapes are arranged on 2 rows, not 3
ones.
(cherry picked from commit 5d899bf3ee59a226f855c8c56389344862efaa95)
Change-Id: I4eb2f06676df11c1432e0934ca3a0ec8891c5843
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103702
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This is needed, but not enough to have the correct width for each shape
and spacing item on the path of the snake. Currently we give the same
width for all children, while the shapes typically have a larger width
than the spacings.
(cherry picked from commit ab291c94fb5338a1cf0ab8fe7cbf57dd5c5f81cb)
Change-Id: I4e2638ea5b566c21cb1cf503a8cf2e5d35256e3c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103701
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
If the child's aspect ratio request will shrink the width, then take
that into account when calculating how many rows / cols we need.
This reduces the number of columns for the bugdoc from 4 to 3, which is
needed, but not enough to render it correctly.
(cherry picked from commit acc9aead3cc5162379d34a455aa15f7b13907cf1)
Change-Id: I1d02df4834b8a2ce97d5e006db0e3135d3d42917
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103700
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
When importing writerfilter, we change to oox when
importing images. This transition doesn't store any
previous contexts and all instances are reset. The
problem occurs when we have identical images because
the transition erases all caches we have to determine
if an image has already been imported or not, which
causes that we import the same image multiple times
which create unnecessary copies.
This introduces the XGraphicMapper, which can be used
to store the XGraphic for a key and can be transferred
between writerfilter to oox. With this we can remember
which images were already imported and don't create
unnecessary internal copies which decreases memory.
This also includes a test which checks that the import
and export doesn't produce unnecessary copies of
identical images. The test checks that for OOXML, ODF
and MS Binary formats.
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103283
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
(cherry picked from commit d0efd878dc41e3913a2d91ff4b5c335c1d71a85c)
Change-Id: I33dc19218c565937fab77e132b3a996c51358b6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103407
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Reference OOXML (Appendix B.5.1, line 248)
Change-Id: Idf5c2546b4ad65c8e78ca03e18ecfa575ef17fe8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103005
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
(cherry picked from commit de59062d95605e5c91d687e3441399ffb05ff2dc)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103051
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Regression from commit 89f0af144c18efafe2573801641689a1432c0cae (tdf#113198 set
default shape paragraph alignment.., 2019-11-19), the old bugdoc had this
markup:
<a:bodyPr ... anchor="ctr"/> (centered)
The new bugdoc has 2 shapes with text:
<a:bodyPr .../> (aligned to left)
<a:bodyPr ... anchorCtr="1"/> (should be centered)
"anchor" is about vertical, "anchorCtr" is about horizontal centering of text.
Checking what the binary filter does, it maps horizontal centering to
TextHorizontalAdjust, so fix the original bug differently, by leaving
ParaAdjust alone, and tweaking TextHorizontalAdjust intead: this keeps the old
bugdoc working but fixes the new one.
This caused a number of "change detector" XML-based tests to fail: all of them
are unchanged visually, so the XML files are adapted to the new state.
The tdf#113198 fix itself was fixing a regression from tdf#104722, and that
commit had no testcase, I tested that we don't regress there, manually.
(cherry picked from commit 10bb02efd8afd42e633e370480104e2575546d8e)
Change-Id: I81a7b3e8c76bfbce5c5569d16d5238958ac20f75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103136
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ie3e00e8195239e6570bfe76c2451bae11c209145
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102999
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
(cherry picked from commit a11bb74d4f464e9639ddb5b8d87dc4770663fea8)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103045
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Which defines that a data node has text properties as direct formatting,
so autoscale should not happen.
We decide autofit at a shape level, smartart defines custom text props
at a data node level. So take the shape, go to its first presentation
node, get its data node and see if it has custom text props. If not,
continue to scale text down till it fits.
smartart-autofit-sync.pptx is extended to contain a 3rd shape: the first
two have their autofit scaling synchronized, while the 3rd has a fixed
font size of 10pt.
(cherry picked from commit 89b385c2336e5b3868d2a040e11134b349b7d010)
Change-Id: I6caacdaab9a36072b9ad5021bd217c955b09b790
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102727
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
When 2 or more shapes have their text set to autofit and they have a
constraint like:
<dgm:constr type="primFontSz" for="des" forName="node" op="equ"/>
Then make sure that the automatic font size is the same for all shapes
and all content fits, by using the smallest scaling factor from all
relevant shapes.
Some rework is needed, because normally oox::drawingml::Shapes don't
have access to their parents, at the same time there can be multiple
SmartArts on a single slide, so storing the grouping info in the filter
is problematic, too. Solve this by storing the grouping in the toplevel
oox::drawingml::Shape and exposing them in XmlFilterBase just during the
time the children of the toplevel shape of the SmartArt are added.
This works, because we know SmartArts can't be nested.
(cherry picked from commit 1bd3474c7c7945e1182dfbaca89be05ea98dd3e8)
Conflicts:
include/oox/core/xmlfilterbase.hxx
oox/source/drawingml/diagram/diagram.cxx
Change-Id: I6c591eadc7166c7c42752650afdb7ee1e416cff6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102726
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit 111c260ab2883b7906f1a66e222dbf4dc3c58c4f.
Change-Id: I60c54b506f6721f08a21ebcfb306f38dd9ebff62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101328
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
During import we were rotating only custom shape. Not its bitmap.
Custom shape and its bitmap rotated with same rotation value
in that commit.
Change-Id: I02d19c820670df7b4d1622836156c6bf8ed1c154
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101255
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
(cherry picked from commit 9fe881410909c5273cef517433411bc4eceee294)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101161
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
ComplexShape::implConvertAndInsert() returns early in the graphic object
shape case, so stroke model is not applied at all.
Also fix a problem in ShapeBase::finalizeFragmentImport(), where the
shape type had no stroke, but the shape itself had, and the later should
win.
The warning in OleObjectGraphicDataContext::onCreateContext() now points
out that <mc:AlternateContent> is ignored as a child of <a:graphicData>,
which probably should be addressed at some stage, but it's not required
to fix the missing stroke.
(cherry picked from commit b2d834d6727626f070bb4dde3e1c65da1169f729)
Conflicts:
oox/qa/unit/vml.cxx
oox/source/vml/vmlshape.cxx
Change-Id: I4ab43b4c6d40d9f43caad22b85f5b885fa8b4ef1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100972
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I402a40be7e8899ca017996f2bf77a2fb884b9462
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100372
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
(cherry picked from commit 33696b2820ce3c8b21b753d2c2bf92345ecb9276)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100356
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Change-Id: Ied1a03ff9f4556a551738b698ccb284fe74299da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100414
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100828
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Change-Id: I0a1b1dc2f9b314858ed90347065407bcd1dbbb73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100311
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100827
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
LibreOffice imports multicolumn texboxes as tables. When
document has numCols=2 (or more) attribute at slidelayout and slide,
the table rows and columns duplicates.
maPPTShapes vector holds our PPTShape objects, hasSameSubTypeIndex
function finds the status that I mention above. So that we can prevent
that duplication.
Change-Id: Iee03d130452a16e9b46d471a9b6ed5910e6351ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99279
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100826
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
|
|
Impress core only support a single step, improve the conversion from
multi-step to single step to take transparency into account explicitly.
Once we select the widest segment, look backwards and forward if there
are other next segments which have the same RGB color, just different
transparency and include them. This helps in general, because in case a
0% or 100% transparency is mishandled, that's very visible.
(cherry picked from commit 73993fdb5d4b507694cd0edf80887d19f7e2bf9a)
Conflicts:
oox/source/drawingml/fillproperties.cxx
Change-Id: I11d593c01a6a4b16149ce74c1408c2a39895e941
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100287
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
In case of solid color fill a transparence gradient was not saved.
OOXML has no separate element for gradient transparency but has
transparency in color gradient stop elements. The patch detects
a transparence gradient, combines it with the fill color and exports
it as gradFill element.
The import was already correct, besides a wrong start or end value
in case of a symmetric gradient, which becomes AXIAL in LibreOffice.
(cherry picked from commit d187f22b7ff73954e1da39fb954c64bc315298cb)
Conflicts:
oox/source/drawingml/fillproperties.cxx
sd/qa/unit/export-tests-ooxml1.cxx
Change-Id: I4243656821629f90125d0408a38165a8a29e6e24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100286
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
When we don't have type attribute on slide but have on
slidelayout we have to use it instead of default type.
Change-Id: Ibb874b5ee39c48641484fe1a8686f66c31695f76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99904
Tested-by: Jenkins
Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100097
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
This changes the order of children, which matters when they have no
explicit ZOrder. With this, the text shapes on the arrow shape are on
top of the arrow, not behind it.
The trick is that nominally chOrder can be "t"(op) or "b"(ottom),
defaulting to bottom, but there is a difference between an explicit "b"
and not setting it. When not setting it, the layout node is expected to
inherit it from its parent layout node, recursively.
This would probably make sense for other algorithms as well, but set it
only for the linear algorithm for now, as that's where we have a bug
document showing the PowerPoint behavior.
(cherry picked from commit 3c185bf386b4c9609ab32d19bf95b83fe0eeeea3)
Change-Id: I433f92c620149ef5590aebc8cbf43110e1d2fb85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100115
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Constraints are OK to request more, but it seems PowerPoint doesn't
allow leaving the parent, which simplifies the layout as well.
(cherry picked from commit b7481a026348c3417fa13a440312521dccee9ec8)
Change-Id: Id67a8740f1eff506e4beae0c797ad50e0218dfe6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100114
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
With this, finally the arrow shape has the correct horizontal position
and width, even if the markup is as complex as the PowerPoint UI
generates it (the previous version was a more minimal version).
(cherry picked from commit 880673412143a7db7ea1bf4766040662dfc085dc)
Change-Id: I59f237c582053067e890180a1ae40471e5f46dea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100113
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
When constraints request a width which is larger than 100%, we scale
down. Then rules decide which children should be scaled down and which
ones stay as-is.
This commit adjusts the size of children which have no rule, but their
size has a constraint that they're a fraction of a scaled down child.
(cherry picked from commit 91f0f7e5e0a55cb1dbd729a1d7de52388b1cfb15)
Change-Id: I0a007d82f49f18951215afb1bfe8c0f1328ecd41
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100111
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The bugdoc has an arrow shape which is 100% wide, and there are multiple
shapes before it, which also have a 100% wide constraint. The reason
PowerPoint scales down the shapes (but not the arrow) is because rules
declare it should happen this way.
So start taking rules into account in linear layouts.
(cherry picked from commit 0024c48b4822062995effed7db4f1281196384bb)
Conflicts:
sd/qa/unit/import-tests-smartart.cxx
Change-Id: I352443277e88be0eb711659489587127727a258f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100110
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
I have a linear algorithm where some elements should be scaled down, but
not all of them. These requirements are described using rules. This
commit just adds the parsing for them, so that later
AlgAtom::layoutShape() can create an improved layout, taking rules into
account.
(cherry picked from commit 6ca5412bac9e3da5cd20f315fc853c7733f10858)
Change-Id: I5f0f9ffcaff75a804796851e48a9ce10583ec362
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100109
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...during CppunitTest_sd_import_tests_smartart:
> oox/source/drawingml/diagram/diagramlayoutatoms.cxx:656:50: runtime error: signed integer overflow: 1924451 - -2147483647 cannot be represented in type 'int'
> #0 in oox::drawingml::AlgAtom::layoutShape(std::shared_ptr<oox::drawingml::Shape> const&, std::__debug::vector<oox::drawingml::Constraint, std::allocator<oox::drawingml::Constraint> > const&, std::__debug::vector<oox::drawingml::Rule, std::allocator<oox::drawingml::Rule> > const&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:656:50
> #1 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::AlgAtom&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:202:19
> #2 in oox::drawingml::AlgAtom::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:386:14
> #3 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16
> #4 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:243:5
> #5 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14
> #6 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16
> #7 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:245:5
> #8 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14
> #9 in oox::drawingml::LayoutAtomVisitorBase::visit(oox::drawingml::ForEachAtom&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:98:20
> #10 in oox::drawingml::ForEachAtom::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:167:14
> #11 in oox::drawingml::LayoutAtomVisitorBase::defaultVisit(oox::drawingml::LayoutAtom const&) at oox/source/drawingml/diagram/layoutatomvisitorbase.cxx:32:16
> #12 in oox::drawingml::ShapeLayoutingVisitor::visit(oox::drawingml::LayoutNode&) at oox/source/drawingml/diagram/layoutatomvisitors.cxx:245:5
> #13 in oox::drawingml::LayoutNode::accept(oox::drawingml::LayoutAtomVisitor&) at oox/source/drawingml/diagram/diagramlayoutatoms.cxx:1452:14
> #14 in oox::drawingml::Diagram::addTo(std::shared_ptr<oox::drawingml::Shape> const&) at oox/source/drawingml/diagram/diagram.cxx:122:30
> #15 in oox::drawingml::loadDiagram(std::shared_ptr<oox::drawingml::Shape> const&, oox::core::XmlFilterBase&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, oox::core::Relations const&) at oox/source/drawingml/diagram/diagram.cxx:356:15
> #16 in oox::drawingml::DiagramGraphicDataContext::onCreateContext(int, oox::AttributeList const&) at oox/source/drawingml/graphicshapecontext.cxx:252:9
> #17 in non-virtual thunk to oox::drawingml::DiagramGraphicDataContext::onCreateContext(int, oox::AttributeList const&) at oox/source/drawingml/graphicshapecontext.cxx
> #18 in oox::core::ContextHandler2Helper::implCreateChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx:94:34
> #19 in oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx:191:12
> #20 in non-virtual thunk to oox::core::ContextHandler2::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at oox/source/core/contexthandler2.cxx
> #21 in (anonymous namespace)::Entity::startElement((anonymous namespace)::Event const*) at sax/source/fastparser/fastparser.cxx:432:44
> #22 in sax_fastparser::FastSaxParserImpl::callbackStartElement(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, unsigned char const**) at sax/source/fastparser/fastparser.cxx:1246:21
> #23 in (anonymous namespace)::call_callbackStartElement(void*, unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) at sax/source/fastparser/fastparser.cxx:305:18
> #24 in xmlParseStartTag2 at workdir/UnpackedTarball/libxml2/parser.c:9588:6
> #25 in xmlParseTryOrFinish at workdir/UnpackedTarball/libxml2/parser.c:11378:14
> #26 in xmlParseChunk__internal_alias at workdir/UnpackedTarball/libxml2/parser.c:12280:13
> #27 in sax_fastparser::FastSaxParserImpl::parse() at sax/source/fastparser/fastparser.cxx:1046:21
> #28 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:866:9
> #29 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1369:13
> #30 in oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool) at oox/source/core/fastparser.cxx:121:15
> #31 in oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&) at oox/source/core/fastparser.cxx:129:5
> #32 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) at oox/source/core/xmlfilterbase.cxx:402:21
> #33 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) at oox/source/core/xmlfilterbase.cxx:331:12
> #34 in oox::ppt::PresentationFragmentHandler::importSlide(rtl::Reference<oox::core::FragmentHandler> const&, std::shared_ptr<oox::ppt::SlidePersist> const&) at oox/source/ppt/presentationfragmenthandler.cxx:610:17
> #35 in oox::ppt::PresentationFragmentHandler::importSlide(unsigned int, bool, bool) at oox/source/ppt/presentationfragmenthandler.cxx:348:13
> #36 in oox::ppt::PresentationFragmentHandler::finalizeImport() at oox/source/ppt/presentationfragmenthandler.cxx:499:17
> #37 in oox::core::FragmentHandler2::endDocument() at oox/source/core/fragmenthandler2.cxx:54:5
> #38 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:872:36
> #39 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1369:13
> #40 in oox::core::FastParser::parseStream(com::sun::star::xml::sax::InputSource const&, bool) at oox/source/core/fastparser.cxx:121:15
> #41 in oox::core::FastParser::parseStream(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&) at oox/source/core/fastparser.cxx:129:5
> #42 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&, oox::core::FastParser&) at oox/source/core/xmlfilterbase.cxx:402:21
> #43 in oox::core::XmlFilterBase::importFragment(rtl::Reference<oox::core::FragmentHandler> const&) at oox/source/core/xmlfilterbase.cxx:331:12
> #44 in oox::ppt::PowerPointImport::importDocument() at oox/source/ppt/pptimport.cxx:145:17
> #45 in oox::core::FilterBase::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at oox/source/core/filterbase.cxx:485:49
> #46 in oox::ppt::PowerPointImport::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at oox/source/ppt/pptimport.cxx:223:24
> #47 in SfxObjectShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sfx2/source/doc/objstor.cxx:2251:34
> #48 in sd::DrawDocShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sd/source/ui/docshell/docshel4.cxx:399:39
> #49 in SfxObjectShell::DoLoad(SfxMedium*) at sfx2/source/doc/objstor.cxx:738:23
> #50 in SdModelTestBase::loadURL(rtl::OUString const&, int, std::shared_ptr<SfxAllItemSet>) at sd/qa/unit/sdmodeltestbase.hxx:181:30
> #51 in SdImportTestSmartArt::testText() at sd/qa/unit/import-tests-smartart.cxx:250:37
As discussed on IRC:
> Jul 31 18:52:58 <vmiklos> sberg: yes, that looks reasonable, clearly the
> expectation is that there is at least one element, in which case that
> nVertMin grows from 0 and nVertMax shrinks from
> std::numeric_limits<sal_Int32>::max()
> Jul 31 18:54:43 <vmiklos> sberg: sounds like i made that mistake in
> acdde3c643fde015214c546b1567727272ea799e, but recently i added a test that
> now uncovered the problem :)
(cherry picked from commit ae4a69d7559a537e86630b2890d28b0d8f6f47d0)
Change-Id: I0ee11dbab568af788f9e2786c3dca2c1a5e1ee08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100112
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
There were two problems here:
1) Our chart model expects the char formatting of a data label as direct
formatting, so in case <c:dLbl> has no such formatting, but <c:dLbls>
has, oox has to explicitly inherit.
2) The data label char formatting is represented using
chart::FormattedString, but the char format of it is not (yet) exported
to ODF. Given that the char format of the series and the individual data
labels is the same, restore the same formatting on import to please
rendering.
With these, finally the chart labels in the bugdoc are white, not black
(and have a dark background, so they are readable).
(cherry picked from commit 8a43bfeffab9009c9f373e883fef87af1a7b3843)
Change-Id: Iebac5ce0be31a59bafb0f9fe7636330585e33822
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98810
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Both the chart and the containing document has one, but the intention is
to insert this into the chart one.
This is needed, but not enough to render the right hatch for data
labels.
(cherry picked from commit e18bc316efbd815b047f4e19ebd033e7a842d10d)
Conflicts:
oox/source/drawingml/chart/seriesconverter.cxx
Change-Id: I485d84e2ae33728963b648c05e730d418567fc0e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98809
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(cherry picked from commit 6f752061d5153da50d6f536d506358c8f512a397)
Conflicts:
oox/source/drawingml/chart/seriesconverter.cxx
Change-Id: I2db64489c86e4381167eb13af4ab5118113960d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98808
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(cherry picked from commit 603df08a1e0211099ce2cf258cfe64a74ed6ded9)
Conflicts:
oox/source/drawingml/chart/seriesconverter.cxx
Change-Id: I8a3ef6e60d4f2a13310bb9a8fc4eb873df3f9b4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98807
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Commit 682ab832522b1349f1714bcb16f6e83468ea2920 (drawingML
export\import: cropping of shape's fill texture, 2014-02-12) improved
the DOCX filter, so the fill rectangle of a custom shape with bitmap
fill is handled.
The problem is drawingML has a source rectangle (similar to our crop
rect) to limit the usage of the bitmap, and also it has a fill rectangle
in case some margin is wanted around a stretched bitmap. We don't have a
mapping for the later.
Fix the problem by limiting the above work for DOCX, this way PPTX's
source rectangle won't be turned into a stretch's fill rectangle.
This way no unwanted margins will appear around the image -- those
margins can be large enough that the image effectively disappears on
export.
(cherry picked from commit b00e43fa5848be0cc7ba81b185021511d94cdc00)
Change-Id: Ic35063545a56eec9eaf885bbd397a854705d134f
|