| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: Icd00e2aaa5932564668cd12ce4ee63aecc34419a
Reviewed-on: https://gerrit.libreoffice.org/71305
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
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.
(cherry picked from commit 943a534ac7cb3df513583e226c986dafd8ba246b)
Change-Id: I0063e88d510250652d2b14856df3bd431681422d
Reviewed-on: https://gerrit.libreoffice.org/71115
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This is a combination of 7 commits.
This is the 1st commit:
oox smartart, picture strip: handle bitmap fill of pres nodes
There were two problems here:
1) We did not import bitmap fill from presentation nodes.
2) Presentation nodes contained properties with reference semantics, so
if you set a bitmap fill for a first and a second shape, then at the end
both shapes contained the second bitmap.
With this, both bitmaps are imported exactly once.
(cherry picked from commit 333e9ea15bb57cf1c87ac2ea150de1e3fd79cfcb)
This is the commit #2:
oox smartart, picture strip: fetch # of children only once in snake algo
No functional changes intended.
(cherry picked from commit 90372d52fdcc378473b89f4e6f2de0e206c110ef)
This is the commit #3:
oox smartart, picture strip: expose aspect ratio of children for snake algo
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.
(cherry picked from commit a1e10b7968fbf4dba962349be8a6dfb0cb1d3176)
This is the commit #4:
oox smartart, picture strip: fix too many columns with aspect ratio request
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.)
(cherry picked from commit 159e33ec661b2ce038b2642b2f30600ce7901d1b)
This is the commit #5:
oox smartart, picture strip: fix lack of spacing around the picture list
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.
(cherry picked from commit 0a29c928afa74123bca05dc089c751603d368467)
This is the commit #6:
oox smartart, picture strip: fix lack of margin in text shapes
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.
(cherry picked from commit 279c7f83a57c4d3991930ee80e9d9c287c21270a)
This is the commit #7:
oox smartart, picture strip: fix too wide child shapes
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.
(cherry picked from commit f4fbb127897ea6afe27055d3b6cfcb0441080902)
Change-Id: I7bac764c031e80bac532c4f97ebd5b5096401096
Reviewed-on: https://gerrit.libreoffice.org/68679
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Set the data label separator to "new line" if there is not
present explicit point separator and the "percentage format
wins over number value format". In MS-Office (2007/2010/2013/2016)
the defult separator is the "new line" in that case, any other
case the separator is a semicolon.
(cherry picked from commit de73efb96fbb1d268caea0f41acbe20a234ec59f)
(cherry picked from commit 42fd10b0ab6c6f65ba6394f9ae216c0f13973221)
Change-Id: I9ee0fb9f98fc1bb322892616af50954f4f8db0f9
Reviewed-on: https://gerrit.libreoffice.org/67758
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Export the shapeProps (fillstyle, linestyle, linewidth,
linecolor etc.) of the Error Bars to OOXML.
Change-Id: Iff74fa463fdd0fb6ed95e4d1bf0d3e906349860c
Reviewed-on: https://gerrit.libreoffice.org/67825
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit b89f239aa9d3d4660380bbd0c893aecde0986032)
Reviewed-on: https://gerrit.libreoffice.org/67950
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
This is a combination of 6 commits.
This is the 1st commit:
oox smartart, cycle matrix: fix counting presentation children
The markup is:
<dgm:if name="Name6" axis="ch ch" ptType="node node" st="1 1" cnt="1 0" func="cnt" op="gte" val="1">
Where PowerPoint evaluated the condition to true, but Impress evaluated
to false. This means that the undocumented relation between the child
lists is "OR" (not "AND").
Also, our code assumed that "node" has to be a data node (not
presentation node), but it seems the only way this condition can be true
if presentation children is also counted. (The presentation node in
question is not a presentation of anything.)
(cherry picked from commit e3c6f249c10f7f1bcc528e643f5723288c514b29)
This is the commit #2:
oox smartart, cycle matrix: handle left/bottom constraint in composite algo
The bugdoc has 3 shapes in the "outer" circle which have a position
where either x or y is not 0. But these are defined using constraints
talking about the right or bottom edge of the shape.
Map that to top/left, given that we already know the shape size.
(cherry picked from commit b9b4e9223b6c0d6e0b48b694c9aabbe54a250660)
This is the commit #3:
oox smartart, cycle matrix: fix too large height in composite algo
The user-level problem was that the height of the entire smartart was
too large. The reason for this was that:
- composite algorithm gets the constraint height should be 77% of width,
this means 6096000 -> 4693920 EMUs
- at the same time the parent container is already smaller, 4064000 EMUs
- a few lines later we already limit the max height with std::min(), but
in the meantime an incorrect y position is calculated, exactly due to
the lack of early limited height
Solve the problem by making sure composite algorithm never works with a
height (even when using it to calculate vertical center) that exceeds
the height of the parent.
(cherry picked from commit 5b2e38e0cfc7006d6982f741cf158a8a98dc8630)
This is the commit #4:
oox smartart, cycle matrix: handle aspect ratio in composite algo
This way the 4 quadrant shapes in the center of the SmartArt form a
circle, as width is shrinking.
It's not height growing, as OOXML spec clearly says "ar" always just
shrinks one axis.
(>1 and <1 "ar" is to be handled when they are seen in action in an
actual document.)
(cherry picked from commit 34383064ac061497b0c46c449313877c6b6a2087)
This is the commit #5:
oox smartart, cycle matrix: handle destination order in connections
It is possible to have connections from multiple data nodes to the same
presentation node with a presOf type. We use to order these based on as
they appear in the data XML, but we need to order them according to the
destOrd attribute.
Introduce an std::map for that, so get ordering automatically as we
iterate. Turn the std::pair into a struct to make the code a bit more
readable.
(cherry picked from commit ecb733da58b74714eb66d2063a2835ce5c471870)
Conflicts:
oox/source/drawingml/diagram/diagramlayoutatoms.cxx
This is the commit #6:
oox smartart, cycle matrix: fix fill and line props of shape
The topmost shape may not have 0 depth, but something larger.
In that case at least it's safe to still use fill & line properties. The
B1 quadrant of the test file now has the proper orange background, and
B2's border is also properly orange.
(cherry picked from commit 8193e697d286595aa62859011761adeb002244e3)
Conflicts:
oox/source/drawingml/diagram/diagramlayoutatoms.cxx
Change-Id: Iccc5f6993693a0f1cf8f50d163003c24d3ad690e
Reviewed-on: https://gerrit.libreoffice.org/68144
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
This is a combination of 3 commits.
(cherry picked from commit 48ef20f2039d1a300a4324072e9b712c9994b406)
(cherry picked from commit 00e89430a2f8cd1f9ec702a7583a1e4c886a2b46)
(cherry picked from commit 1f0206d940cd8f7fb627a59cfe4165c0bfebaf46)
Change-Id: Ic6fa6f335623e2114fc8bea76dc54833284d2a02
Reviewed-on: https://gerrit.libreoffice.org/68150
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Export the data label separator XML tag and
the separated character to OOXML.
Change-Id: I9b3bcb588e42a42494107ebde70f4a72492cfac4
Reviewed-on: https://gerrit.libreoffice.org/67753
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit e32e5e61b509dcae0462419acfc556d445895840)
Reviewed-on: https://gerrit.libreoffice.org/67772
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Set the TextBreak value automatically true, only if the X axis labels
rotation is 0 degree. The MS Office using a similar method because
there is no any XML tag in the OOXML standard which refer to this setting.
Change-Id: Ie84a95935f0d5c4c1f9a30803e22572141385960
Reviewed-on: https://gerrit.libreoffice.org/65853
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
(cherry picked from commit 015569fc919b702f7a1b0f09038bafa9f104ca70)
Reviewed-on: https://gerrit.libreoffice.org/65934
|
|
I imagine it should have been seqPos-(idPos+2)
seems to be like this since the initial commit of
commit 091fe76b6329b4bb974987554369cbfadd8f2401
Date: Tue Jun 30 12:55:18 2015 +0300
tdf#87348 implement mso-next-textbox vml-style textbox chaining import
Change-Id: Ic2f527ede2102c01c8589d58d8c705d59b0a6ffe
Reviewed-on: https://gerrit.libreoffice.org/67453
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Embedded XLSX spreadsheets and other OLE objects
became small in Writer after a roundtrip between
LibO and MSO, caused by the empty drawing path of
OLE shapes.
Change-Id: I4cd39d4bcd6707cc5a3b8e40dde8c6148a20cabc
Reviewed-on: https://gerrit.libreoffice.org/66053
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit bdb0177b550d27a541cdfc0668714b2e9ac28540)
Reviewed-on: https://gerrit.libreoffice.org/66689
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This is a combination of 10 commits.
This is the 1st commit:
oox smartart, org chart: add initial hierChild/Root algorithms
hierChild is supposed to align and position its child layout nodes in a
linear path under the hierRoot layout node, so initially just use a
simple vertical layout algorithm.
(cherry picked from commit 3103f9f9461f6eabb61a70be73862ef4be98010e)
This is the commit #2:
oox smartart, org chart: handle multiple elements in hierChild
In case one manager has multiple employees, then we laid out only the
first one. Recognize non-assistant type as the node type (as a start) to
get the correct number of employees (when there are no assistants), and
also render employees on a horizontal (and not on a vertical) path.
With this, the 1 manager and multiple employees case looks reasonable.
(cherry picked from commit dcd378bf614c99d705312259a0a0a25b40d88e2b)
This is the commit #3:
oox smartart, org chart: fix font color when defined with quick styles
createStyleMatrixContext() assumed that <dgm:style> contains
<dgm:fontRef>, but it contains <a:fontRef> instead.
This resulted in a 0 mnThemedIdx, which meant that since commit
89206c472ecf18bfde6824cea8004921cd404365 (bnc#862510: PPTX import: Wrong
text color inside shape, 2014-12-21) we ignored the theme color in
oox::drawingml::Shape::createAndInsert().
(cherry picked from commit 5dfd5755c709e91d2903bd7be4582f7832e89780)
This is the commit #4:
oox smartart, org chart: fix vertical order of assistant nodes
It seems the manager -> assistant -> employees ordering is not part of
the file format. The order is stored twice in the file: the hierRoot
algorithm has 3 layout nodes as a children, and also the data model has
an order of the presentation nodes: both describe that employees go
before assistant nodes.
In contrast to that, PowerPoint orders XML_asst nodes before XML_node
ones, so teach the hierRoot algorithm about this.
This requires tracking the data model node type for each in-diagram
drawingML shape, so that layout can determine if a hierRoot algorithm
children has an assistant node or not.
(cherry picked from commit 22086e70c4f3bb41620ff81ecaf57fd2af6ccbce)
This is the commit #5:
oox smartart, org chart: handle multiple paragraphs on data node
This problem was similar to the one fixed in
cfa76f538a44d4396574ece59e8a3953c22c6eb7 (oox smartart, accent process:
handle multiple runs from a data point, 2018-11-21), but this there we
handled multiple runs and this handles multiple paragraphs.
It seems some smartart types allow multiple paragraphs in a diagram
node, others only allow multiple runs. Org chart is in the former
category.
(cherry picked from commit dfc97dd381ef516ca4a7e99b29f9da1033a380f4)
This is the commit #6:
oox smartart, org chart: fix height of manager nodes without employees
Employees and/or assistants reduce the height of managers -- this effect
is wanted even if there are no employees/assistants.
(cherry picked from commit 8638cc1b737195df16a160b148d2cd2c68131174)
This is the commit #7:
oox smartart, org chart: improve width of non-manager nodes
The default case is that all managers have assistants/employees, so
nodes under a manager can only use the horizontal space under the
manager to avoid overlapping.
But in case the previous / next sibling of the manager have no child
nodes (assistant/employee) then we can use that space to make the child
nodes larger. This improves readability of the chart's text a lot and
brings the layout closer to what PowerPoint does for the same input.
Handle all this in the hierChild algorithm, i.e. the container for a
list of assistants or a list of employees, which means "parent" in this
context always refers to a manager node.
(cherry picked from commit 3a655975e5ea43417885513d0752da3627dd25ed)
This is the commit #8:
oox smartart, org chart: implement support for hierBranch conditions
The relevant part of the layout is the <dgm:layoutNode
name="hierChild2"> element that has a <dgm:choose> with two branches:
<dgm:if name="Name34" func="var" arg="hierBranch" op="equ" val="std">
<dgm:if name="Name36" func="var" arg="hierBranch" op="equ" val="init">
The connectors were missing as we took the first branch
(ConditionAtom::getDecision() returned true if the arg was hierBranch),
even hierBranch on the parent layout node was set to "init".
With this, the correct number of connectors are created, previously all
employee connectors were missing. Their size / position is still
incorrect, though.
(cherry picked from commit ae34f471030869dfc0da1784597cae6f9131f8c5)
This is the commit #9:
oox smartart, org chart: fix shape type of connectors
PowerPoint renders these as bent connectors, not as arrow shapes.
Also add a bit of vertical spacing between the nodes, otherwise the
connectors have no way to be visible. Their position is still incorrect,
though.
(cherry picked from commit 1791e08e9f27453ac5563ef400c715e30c791133)
This is the commit #10:
oox smartart, org chart: fix position and size of connector shapes
Finally the bugdoc rendering result is reasonable and even looks like a
tree as it should.
(cherry picked from commit 2bfb9117b287a371066a157267614b9bdb367d71)
Change-Id: I4e7a729afd3d2c5af2e7f41903737bd56be406fa
Reviewed-on: https://gerrit.libreoffice.org/66693
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Each of the Column and Line Chart creates it's own x and y Axes.
So now the LineChart Exporter Method uses the same Axes as the BarChart.
Thanks for the help:
- Balazs Varga
- Adam Kovacs
Change-Id: Ie763cf831c2ce63ef204d1fdcbff634e7ca8fad5
Reviewed-on: https://gerrit.libreoffice.org/64146
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Reviewed-on: https://gerrit.libreoffice.org/65449
|
|
Regression from commit d5c934d150cb6cea5f96cbbee4fb5e8312bf027e
(n#792778 DOCX import: parse group shapes in oox only, 2012-12-14),
where where manual wordprocessingML -> drawingML translation did not
handle this character property.
Change-Id: I87481bc9c26651fd15dd39a58a92f467e8311256
Reviewed-on: https://gerrit.libreoffice.org/65289
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit dafbc86037d63e938967c0f501bdfe3ae19fa992)
Reviewed-on: https://gerrit.libreoffice.org/65413
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
The MS Office UI allows values only in range of [-90,90].
Because of this, we should reflect the angle if the Textrotation
is between 90 and 270 degree. Also we have to recalculated the
the Textrotation between 270 and 360 degree, because the OOXML
counts clockwise.
Change-Id: I2fbd53d93ab2e8ea4e26840fd056de20b337daa3
Reviewed-on: https://gerrit.libreoffice.org/65194
Tested-by: Jenkins
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
(cherry picked from commit 527772d8dfcedad56b11b5b13540ec1defa464e5)
Reviewed-on: https://gerrit.libreoffice.org/65351
Reviewed-by: Balazs Varga <balazs.varga991@gmail.com>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Bulleted paragraphs had a large left indent because we assumed the
bullet levels are inherited from the normal master page styles.
But that's not true, as
<https://support.office.com/en-us/article/add-bullets-to-a-shape-in-a-smartart-graphic-47edc03d-a2f8-4b54-acfd-ca103c515ab4>
points out:
"It is not possible to change the bullet style for text in a SmartArt
graphic."
This explains why the margin and bullet char info is missing from the
file format, and hints that just hardcoding these to the importer is
correct.
The result is less linebreaks in the shape text and the lost bullets are
also fixed.
Change-Id: I60bbee75f3e834551ebb1963a2f42101f3bd91d4
Reviewed-on: https://gerrit.libreoffice.org/65168
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit 6277a767f33bb5327408dafff2fed199087e938d)
Reviewed-on: https://gerrit.libreoffice.org/65254
|
|
The information is needed by the linear layout, but it's provided by a
child algorithm of type "space", with possibly multiple foreach atoms
in-between.
So start supporting a custom space factor by reading it from
constraints, but still assume a fixed layout node name, as it's tricky
to look that up.
Change-Id: I2aa8db8823694618d8ca6707ddcd71715a65b831
Reviewed-on: https://gerrit.libreoffice.org/65049
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit ee6787fc5597b7f730c4ee3a1f2a1b261d0a5644)
Reviewed-on: https://gerrit.libreoffice.org/65253
|
|
The constraints explicitly said that the width should be larger than the
height, but it was the opposite as constraints were not parsed.
Unfortunately it would be too brave for globally start handling all
constraints which lack a forName, so add a switch to opt in for this,
and use that with the conn algorithm. All clients should migrate to
bRequireForName=true at some stage, though.
Change-Id: I24ae79b141c0f7a11e4d19f141759fc1dd2169b0
Reviewed-on: https://gerrit.libreoffice.org/64350
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit ddc2786831367577967e806d603f337a2e42806a)
Reviewed-on: https://gerrit.libreoffice.org/65252
|
|
The shape was created, but we literally tried to create a "conn" type,
while that has to be resolved to the relevant arrow type based on the
context.
This means now arrows show up between the parent-child pairs (but their
size is not yet correct).
Change-Id: I82594e46579e4ef723093e1dd0ba31bfcbbec4a0
Reviewed-on: https://gerrit.libreoffice.org/64348
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit 7f66a340933339974b5c6d70af4ae3c17e4f001a)
Reviewed-on: https://gerrit.libreoffice.org/65251
|
|
Currently the accept process document creates 0 connectors. Instead, it
creates empty custom shapes: this commit fixes the loop, so that only
one of them is created.
The whole purpose of the follow sibling axis is that N - 1 connectors
are created for N shapes, not N connectors.
Change-Id: I54244c7615b83f607ef53a4ff8d01d3c9594856e
Reviewed-on: https://gerrit.libreoffice.org/64122
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit aedc5427e4b6645ff3257e523c33190cf5e1934d)
Reviewed-on: https://gerrit.libreoffice.org/65250
|
|
Multiple paragraphs indeed are impossible for those containers, but
multiple runs can happen.
Change-Id: I47a2f72cae4cbb822f31a5b7cd0169a663e2a6a8
Reviewed-on: https://gerrit.libreoffice.org/63732
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit cfa76f538a44d4396574ece59e8a3953c22c6eb7)
Reviewed-on: https://gerrit.libreoffice.org/65249
|
|
Linear algorithm had an idea how to take width from constrains, but that
was unused for embedded child algorithms.
Change-Id: If4c497e053ea0d134a1ffc529f1d233ec4fc50db
Reviewed-on: https://gerrit.libreoffice.org/63725
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(cherry picked from commit 67e062aa5e5946d4985921fe2b6f87766f363ddc)
Reviewed-on: https://gerrit.libreoffice.org/65248
|
|
With adding the PROP_FillBackground property to spnCommonPropIds and
spnFilledPropIds the hatch background color imported correctly,
an will not disappear.
Change-Id: I56745179236d2912a2d5c8585098e54acc4e3062
Reviewed-on: https://gerrit.libreoffice.org/63069
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit dddcfa0089bc84965d7a2c94f5f738a325cfae78)
Reviewed-on: https://gerrit.libreoffice.org/64944
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Fixing linestyle export of chart wall (plot area) and chart page.
Change-Id: Id5265110352d393d9c3e01ff55cea0770d4e0cef
Reviewed-on: https://gerrit.libreoffice.org/63418
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 5bdc78f65da36d65e94de1e2dde5659f0563f08f)
Reviewed-on: https://gerrit.libreoffice.org/64322
|
|
Change-Id: I2304b6050b786b6e4a9a8a968d7a4846d9da8be8
Reviewed-on: https://gerrit.libreoffice.org/64306
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit 6a04b9298ae993881d20fc4b5aa91516d4df6695)
Reviewed-on: https://gerrit.libreoffice.org/64308
|
|
Change-Id: Ia2c0d6b05385a0f3900e20ef807b869e4098654c
Reviewed-on: https://gerrit.libreoffice.org/63541
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit afe5e1f8de0a25364c8c98b453cfe831330c4eed)
Reviewed-on: https://gerrit.libreoffice.org/63543
|
|
Change-Id: I3cc69a0baebc55ad52b64960657e9daa4be8f39d
Reviewed-on: https://gerrit.libreoffice.org/63510
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
(cherry picked from commit 4bd2e57653ce22044ab984b06c84f22ef287cecf)
Reviewed-on: https://gerrit.libreoffice.org/63512
|
|
The oox::drawingml::Shape -> css::drawing::XShape converter doesn't
support ZOrder, so just give each drawingml::Shape a default ZOrder.
This way the offsets can be applied, and sorting can move the shapes to
their correct place.
This makes parent text of the bugdoc readable.
Change-Id: Ib87a096fba66aad4a4f35d19473ea88dab340fd0
Reviewed-on: https://gerrit.libreoffice.org/63478
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
By Xlsx files, rChartSize is using the Values that it gets from getChartSize(), this is the
same Size as rPageSize. By Docx files rChartSize was a negative number everytime,
so the calcAbsRectangle Method gave back a 'false' Value because of this. The rPageSize shows
at every Debugging, Width = 16000, and Height = 9000 for Docx files, and beacause rChartSize was
equal to rPageSize by Xlsx, I tried rChartSize with this Fixed Size.
Change-Id: Ia29fa3401475c33c1b5e3dde9c3cb030a02cceb4
Reviewed-on: https://gerrit.libreoffice.org/62991
Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
Tested-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
|
|
Change-Id: Ic0ca695a1d9d05418213475a68e233953136cc8e
Reviewed-on: https://gerrit.libreoffice.org/63468
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8889ce8a7d2309b54454cfe4c6421282e1c6e755
Reviewed-on: https://gerrit.libreoffice.org/63434
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I48b8295fc75e40f5d58f99fc2809c28de48771d5
Reviewed-on: https://gerrit.libreoffice.org/63417
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
This algorithm was initially not implemented, because of that it was
not able to show shapes which relates to pyramid, but with this patch,
It rendered correctly except some minor adjustement values issues which
can be fixed in upcoming patches.
Change-Id: I298c812615956d67eb00e1b7544d7b171a4ac14a
Reviewed-on: https://gerrit.libreoffice.org/57241
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
For one, CppunitTest_sw_ooxmlexport6 failed under
-fsanitize=implicit-signed-integer-truncation when passing a negative
ShadowFormat.ShadowWidth into a sal_uInt16 SvxShadowItem (see below).
Fixing the mapping from VML shadow to ShadowFormat in
ShadowModel::pushToPropMap caused ShadowModel::pushToPropMap to fail again,
however, testing against 57811035 in testOuterShdw
(sw/qa/extras/ooxmlexport/ooxmlexport6.cxx).
fa9d574ae1656b64670fbbac64ddd85461698149 "Code changes for fdo#74107:File
Corruption - Issue with outerShdw" doesn't explain how that value came about, so
assume that it was just whatever value happened to be observed in LO at that
time, and now adjust it accordingly. And, for another, opening
sw/qa/extras/ooxmlexport/data/testOuterShdw.docx in LO now produces a green bar
with red shadow at the top of the first page that better resembles the original.
> editeng/source/items/frmitems.cxx:1154:18: runtime error: implicit conversion from type 'long' of value -1160 (64-bit, signed) to type 'sal_uInt16' (aka 'unsigned short') changed the value to 64376 (16-bit, unsigned)
> #0 in SvxShadowItem::PutValue(com::sun::star::uno::Any const&, unsigned char) at editeng/source/items/frmitems.cxx:1154:18 (instdir/program/libeditenglo.so +0x16716ea)
> #1 in BaseFrameProperties_Impl::FillBaseProperties(SfxItemSet&, SfxItemSet const&, bool&) at sw/source/core/unocore/unoframe.cxx:759:48 (instdir/program/libswlo.so +0xba32230)
> #2 in SwFrameProperties_Impl::AnyToItemSet(SwDoc*, SfxItemSet&, SfxItemSet&, bool&) at sw/source/core/unocore/unoframe.cxx:1004:19 (instdir/program/libswlo.so +0xba3cbb9)
> #3 in SwXFrame::attachToRange(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sw/source/core/unocore/unoframe.cxx:2665:20 (instdir/program/libswlo.so +0xba78d71)
> #4 in SwXFrame::attach(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sw/source/core/unocore/unoframe.cxx:3003:9 (instdir/program/libswlo.so +0xba877fa)
> #5 in SwXTextFrame::attach(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sw/source/core/unocore/unoframe.cxx:3242:15 (instdir/program/libswlo.so +0xba926a2)
> #6 in SwXText::insertTextContent(com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&, com::sun::star::uno::Reference<com::sun::star::text::XTextContent> const&, unsigned char) at sw/source/core/unocore/unotext.cxx:619:15 (instdir/program/libswlo.so +0xc2dc17f)
> #7 in writerfilter::dmapper::DomainMapper_Impl::PushShapeContext(com::sun::star::uno::Reference<com::sun::star::drawing::XShape> const&) at writerfilter/source/dmapper/DomainMapper_Impl.cxx:2330:30 (instdir/program/libwriterfilterlo.so +0x14d2953)
> #8 in writerfilter::dmapper::DomainMapper::lcl_startShape(com::sun::star::uno::Reference<com::sun::star::drawing::XShape> const&) at writerfilter/source/dmapper/DomainMapper.cxx:2964:18 (instdir/program/libwriterfilterlo.so +0x132c46f)
> #9 in writerfilter::LoggedStream::startShape(com::sun::star::uno::Reference<com::sun::star::drawing::XShape> const&) at writerfilter/source/dmapper/LoggedResources.cxx:151:5 (instdir/program/libwriterfilterlo.so +0x1763e70)
> #10 in writerfilter::ooxml::OOXMLFastContextHandlerShape::sendShape(int) at writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:1678:27 (instdir/program/libwriterfilterlo.so +0x1ad7fba)
> #11 in writerfilter::ooxml::OOXMLFastContextHandlerWrapper::lcl_createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:1917:63 (instdir/program/libwriterfilterlo.so +0x1ae026e)
> #12 in writerfilter::ooxml::OOXMLFastContextHandler::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:208:21 (instdir/program/libwriterfilterlo.so +0x1aa90d7)
> #13 in non-virtual thunk to writerfilter::ooxml::OOXMLFastContextHandler::createFastChildContext(int, com::sun::star::uno::Reference<com::sun::star::xml::sax::XFastAttributeList> const&) at writerfilter/source/ooxml/OOXMLFastContextHandler.cxx (instdir/program/libwriterfilterlo.so +0x1aa9378)
> #14 in (anonymous namespace)::Entity::startElement((anonymous namespace)::Event const*) at sax/source/fastparser/fastparser.cxx:439:44 (instdir/program/libexpwraplo.so +0x24df4c)
> #15 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:1254:21 (instdir/program/libexpwraplo.so +0x249499)
> #16 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:310:18 (instdir/program/libexpwraplo.so +0x240fee)
> #17 in xmlParseStartTag2 at workdir/UnpackedTarball/libxml2/parser.c:9583:6 (instdir/program/libxml2.so.2 +0x6f9027)
> #18 in xmlParseTryOrFinish at workdir/UnpackedTarball/libxml2/parser.c:11342:14 (instdir/program/libxml2.so.2 +0x7300dc)
> #19 in xmlParseChunk__internal_alias at workdir/UnpackedTarball/libxml2/parser.c:12244:13 (instdir/program/libxml2.so.2 +0x72426a)
> #20 in sax_fastparser::FastSaxParserImpl::parse() at sax/source/fastparser/fastparser.cxx:1081:25 (instdir/program/libexpwraplo.so +0x23e8e7)
> #21 in sax_fastparser::FastSaxParserImpl::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:870:9 (instdir/program/libexpwraplo.so +0x237c3b)
> #22 in sax_fastparser::FastSaxParser::parseStream(com::sun::star::xml::sax::InputSource const&) at sax/source/fastparser/fastparser.cxx:1377:13 (instdir/program/libexpwraplo.so +0x2528eb)
> #23 in writerfilter::ooxml::OOXMLDocumentImpl::resolve(writerfilter::Stream&) at writerfilter/source/ooxml/OOXMLDocumentImpl.cxx:503:22 (instdir/program/libwriterfilterlo.so +0x1a6a8d7)
> #24 in WriterFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at writerfilter/source/filter/WriterFilter.cxx:186:24 (instdir/program/libwriterfilterlo.so +0x1a272bb)
> #25 in SfxObjectShell::ImportFrom(SfxMedium&, com::sun::star::uno::Reference<com::sun::star::text::XTextRange> const&) at sfx2/source/doc/objstor.cxx:2251:34 (instdir/program/libsfxlo.so +0x38d811f)
> #26 in SfxObjectShell::DoLoad(SfxMedium*) at sfx2/source/doc/objstor.cxx:772:23 (instdir/program/libsfxlo.so +0x38a1299)
> #27 in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at sfx2/source/doc/sfxbasemodel.cxx:1795:36 (instdir/program/libsfxlo.so +0x3a4372e)
> #28 in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) at sfx2/source/view/frmload.cxx:688:28 (instdir/program/libsfxlo.so +0x40c49f0)
> #29 in framework::LoadEnv::impl_loadContent() at framework/source/loadenv/loadenv.cxx:1149:37 (instdir/program/libfwklo.so +0x15212f1)
> #30 in framework::LoadEnv::startLoading() at framework/source/loadenv/loadenv.cxx:383:20 (instdir/program/libfwklo.so +0x1511cd6)
> #31 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/loadenv/loadenv.cxx:169:14 (instdir/program/libfwklo.so +0x150d988)
> #32 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/services/desktop.cxx:619:12 (instdir/program/libfwklo.so +0x16705ce)
> #33 in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at framework/source/services/desktop.cxx (instdir/program/libfwklo.so +0x16707da)
> #34 in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at unotest/source/cpp/macros_test.cxx:50:60 (workdir/LinkTarget/CppunitTest/../Library/libunotest.so +0x8f1f6)
> #35 in SwModelTestBase::loadURL(rtl::OUString const&, char const*, char const*) at sw/qa/extras/inc/swmodeltestbase.hxx:762:23 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport6.so +0x2460b1)
> #36 in SwModelTestBase::load(rtl::OUString const&, char const*, char const*) at sw/qa/extras/inc/swmodeltestbase.hxx:717:16 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport6.so +0x2449d6)
> #37 in SwModelTestBase::executeImportTest(char const*, char const*) at sw/qa/extras/inc/swmodeltestbase.hxx:264:13 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport6.so +0x2440bf)
> #38 in testOuterShdw::Import() at sw/qa/extras/ooxmlexport/ooxmlexport6.cxx:924:1 (workdir/LinkTarget/CppunitTest/libtest_sw_ooxmlexport6.so +0x33cf2d)
[...]
Change-Id: Ib26db2f175192c8756f825128fc5b852fcc24abf
Reviewed-on: https://gerrit.libreoffice.org/63355
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
And also add support for merging parent and own constraints in the
layout.
This fixes the lack of vertical position difference between the two
pairs of shapes in the bugdoc.
Change-Id: I3a91c9b0da5eed78a87116ebe0e2751a73e1508f
Reviewed-on: https://gerrit.libreoffice.org/63340
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: Iefc820a4c4bb87fe113f97b085d8e89f30ff2db5
Reviewed-on: https://gerrit.libreoffice.org/63261
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
Change-Id: I7340a561e0df0c781fd834388deb4b9f83800f9b
Reviewed-on: https://gerrit.libreoffice.org/63221
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id2df31daa596a18c79af5fc6ea162deb6e24d5af
Reviewed-on: https://gerrit.libreoffice.org/62958
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id5cddc6d85e227f18d10d7af6a8d4b25c40ab9f3
Reviewed-on: https://gerrit.libreoffice.org/63026
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's possible all children request 100% of space, need to scale down in
that case. This means that children other than the first one is now
readable in the layout result.
Change-Id: I86a05cd77510bbb6686a53e33f13a60034c8e8f6
Reviewed-on: https://gerrit.libreoffice.org/63037
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I43d14025c48878c5bc035d492623f4fc52426e5e
Reviewed-on: https://gerrit.libreoffice.org/62752
Tested-by: Jenkins
Reviewed-by: Katarina Behrens <Katarina.Behrens@cib.de>
|
|
Change-Id: I3068b18f5cff024a48a8f8c68d69cadad30fe4d5
Reviewed-on: https://gerrit.libreoffice.org/62953
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I720d7d4920ae9c2f5d74ad827e1e214a62fe81a9
Reviewed-on: https://gerrit.libreoffice.org/62947
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I4ed97cc6d9f733292156d71551d5ce3af6071445
Reviewed-on: https://gerrit.libreoffice.org/62858
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Sets an explicit fill hatch, or creates a named fill hatch
and stored in a global container. With this patch the
SUPPORTED MS Office hatch styles by LibreOffice, or the custom
LibreOffice hatches will be appeared correctly instead of the
previous display as horizontal lines in LibreOffice.
(The background color of the hatch styles are not imported correcty,
but that is another BUG.)
Change-Id: Ifda9dc805dd08f58db10b35f40d7f511a8614f77
Reviewed-on: https://gerrit.libreoffice.org/62681
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I856345576ff5c10a41509a97ad4539272bd55568
Reviewed-on: https://gerrit.libreoffice.org/62803
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: Id1a0749b78a7021be3564487fb974d7084705129
Reviewed-on: https://gerrit.libreoffice.org/62718
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This gets rid of the horrible hack in gbuild.mk to accomodate the
case-incorrect iOS platform makefiles that cannot be renamed without
upsetting git on file systems that sadly lack the case sensitivity
feature.
Keep the macro defined to IOS though.
Change-Id: I1022bfef4900da00e75fc1ccce786b20f8673234
Reviewed-on: https://gerrit.libreoffice.org/62705
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
|
|
The visible effect of this was that the 2nd level text nodes were
missing from the layout result.
The cause is that when it comes to counting nodes of a condition, we
assumed that the current layout node is a presentation of a model node,
but this is not necessarily true.
Fix the problem doing a "first presentation child of", then a "presentation
of" navigation in that case, which leads us to the correct model node,
so counting its children works.
(An alternative way of getting non-zero children would be a
"presentation parent of" navigation, followed by a "presentation of"
navigation, but that would lead us to the document root, so we would
count the number of 1st level elements, not the correct 2nd level
elements.)
Change-Id: Iccebe0e2e56b7acb7fbe2c38a7c9ebb2abb309b9
Reviewed-on: https://gerrit.libreoffice.org/62703
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
This would create a com.sun.star.drawing.DiagramShape, and work with
that, but nobody implements such a service.
Change-Id: Iaaed3ace95d86e52ba50e059ab89698197709189
Reviewed-on: https://gerrit.libreoffice.org/62671
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
