MS Office has trouble loading the file if you do. There is an exception,
however. A pie chart allows label placement option even when 3D. There
may be other chart types that allow variable label placement when 3D.
Change-Id: I6a9247041ca6ee3ae1b9c245f5919fcb35951f24
- Rotation property is not available for TextFrame in LO.
- Hence grabbaged this value.
- Roundtripped rotation value by converting it properly for both dml and vml textbox.
- Added UT for it.
Change-Id: Ia040d55dc2ea79500df76877ba44a02971c872a8
Reviewed-on: https://gerrit.libreoffice.org/10190
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Previously, we always exported the text of the shape itself. Bring the
VML export in sync with the drawingML export, where we only do that if
the shape doesn't have an associated textbox -- if that's the case, then
export the textbox's text instead.
CppunitTest_sw_ooxmlsdrexport's testFdo69636 is a reproducer for this
problem, the VML assert failed because of the lack of this.
Change-Id: Icb236579da4e3b74e983a95aa5675fed7862d1e1
The import mechanism of custom-dash (a:custDash) was wrong, and imported
wrong values, which causes that if you would import-export-import-export -
you would get inflated values, which might cause a corruption.
The attributes for custom-dash nodes (a:ds) are of type 'PositivePercentage'.
Office will read percentages formatted with a trailing percent sign or
formatted as 1000th of a percent without a trailing percent sign, but only
write percentages as 1000th's of a percent without a trailing percent sign.
During import - LO did not check if it was in '%' format or in
'1000th of a percent' format. So that was fixed. Also - when exporting -
it always exports now in '1000th of a percent' format.
Change-Id: I6bd74df26951974f85173227c832386c70034afb
Reviewed-on: https://gerrit.libreoffice.org/9681
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
When two pictures apply different effects to the same picture, it is
only saved once in the original document. Added a cache to DrawingML
to know if the picture has already been exported, and added a test
for it.
Change-Id: Ia25f3d8f2f46d61f18aefc22fdfdbcdc72f2d916
When Word applies an artistic effect, it creates two embedded files;
one contains the bitmap with the effect and the other one contains the
original bitmap to be able to undo the effect.
This patch reads the original bitmap, stores it in the shape grab bag
and saves it back to the docx file. Added unit tests too.
TODO: right now, if two effects point to the same original bitmap it
is stored twice, we should improve this.
Change-Id: Ia72034a257739abe4ffafa0f42b2a912e4bf9436
Bitmaps can define artistic effects like in the following example:
<a:blip r:embed="rId5">
<a:extLst>
<a:ext uri="{BEBA8EAE-BF5A-486C-A8C5-ECC9F3942E4B}">
<a14:imgProps
xmlns:a14="http://schemas.microsoft.com/office/drawing/2010/main">
<a14:imgLayer r:embed="rId6">
<a14:imgEffect>
<a14:artisticMarker trans="14000" size="80" />
</a14:imgEffect>
</a14:imgLayer>
</a14:imgProps>
</a:ext>
</a:extLst>
</a:blip>
LO core doesn't support them, but I'm preserving them using the shape
grab bag. Bitmaps must not be transformed to a SwXTextGraphicObject
so the grab bag of the XShape is not discarded.
Added several Context and Properties objects on the import side to
traverse and save the relevant tags, and added the corresponding code
on the export side to extract the grab bag and output the effect back.
Also added a unit test for a selection of artistic effects.
TODO: Word saves the original bitmap as an embedded wdp file so the
effect can be undone. We must preserve it too and add the reference to
the a14:imgLayer tag.
Change-Id: I61d427f83e4c8f353eb073da0114cd73ba50ba4b
Transformed the preservation process of shape effects to be able to
store more than one effect. For that we:
* Created the Effect struct and added a vector member to the
EffectProperties struct.
* Changed the shadow effect to use the new Effect struct,
EffectShadowProperties struct is preserved because the direction
field still has some use but we should remove it.
* Changed the structure of the grab bag to store more than one effect.
* Modified an existing unit test to check shapes with several effects.
Change-Id: I0dd908fa1d9578827c02ef6272fc9e2b914391be
Shapes can contain 3D effects like in the following example:
<a:scene3d>
<a:camera prst="isometricLeftDown" zoom="150000"/>
<a:lightRig rig="threePt" dir="t"/>
</a:scene3d>
This patch preserves the a:camera tag and its attributes using the
shape grab bag. It also adds a unit test for this case.
Change-Id: Ic6a78031d2e1fb84a2bacd97b5cc9c55d9dbaa95
The goal is preserving the shadow effect with all its attributes using
the shape grab bag. This is the relevant piece of XML in the document:
<a:effectLst>
<a:outerShdw blurRad="50800" dist="38100"
dir="2700000" algn="tl" rotWithShape="0">
<a:schemeClr val="accent1">
<a:alpha val="40000" />
</a:schemeClr>
</a:outerShdw>
</a:effectLst>
In first place, we added members to the structure EffectProperties to
store the effect name and attributes. Later, when we create the shape,
we add them to the shape grab bag together with the shadow color (if
it is a theme color we store its name and transformations like in
other cases). Finally, we read back all these data from the shape grab
bag and write them back to the document.
I added a unit test for this shape property.
Change-Id: Idda2d5e2970cb8563e2ed13a84b2fa2d4b99aa70
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
Problem : Open docx file which has Text/Picture as water mark.
1. The text is not imported properly also picture water mark is also considered as shape.
2. It writes the watermarks in Document.xml, while it should write in only Header.xml.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8457
Change-Id: Ic988858da25a4cba3ae16e614d920e2e16053a5f
Problem Description:
- If the document contains more than one charts together.
ex.Bar & Line chart
- In that case, LO writes idx & order val equal to 0,
instead of 1 for second chart series.
- After roundtrip, the document get corrupted.
Implementation:
- Added varible to take the series count
in case of multiple chart.
Note:
- Some of the UT's are failing when --enable-dbgutil is enabled.
Change-Id: I40606b4d69026939fa19ae534dd7b2bb36ec97fc
blipFill and other fill elements are not allowed to appear together. See
EG_FillProperties in the OOXML spec.
See fdo31551-2.ods
Change-Id: If5869ab9dc69815938c1f4c6fb180b0c1652ddcc
In Writer shapes had no cropping property so far. With this
commit this is introduced as a FillProperty and has the same
type as the cropping used for pictures
(Picture context menu > Picture > Crop).
Layout and UI will be an other step. On the UI it would be placed
on the Shape context menu -> Area, when Bitmap is selected as fill type.
Note: In case of picture/graphic, cropping property is imported from
and exported to a:srcRect instead of a:fillRect.
Change-Id: Idc1ed2d40cb20b6992e94f14e7e4d853e1f55d02
Fixed import and export for chart wall Bitmap Fill in DOCX
Added UT for the same.
Conflicts:
oox/source/export/chartexport.cxx
Change-Id: Id066b0e4c2007fcdfdbbfa67b40307463bf0cfe7
Fixed import and export for chart wall Gradient Fill in DOCX
Added UT for the same.
Conflicts:
chart2/qa/extras/chart2export.cxx
Change-Id: Ie6caa2b238aeb70f7225145da8c5c78003e73002
Colors can have modifiers like in the following example:
<a:schemeClr val="accent6">
<a:lumMod val="40000"/>
<a:lumOff val="60000"/>
</a:schemeClr>
In the case of RGB colors, the transformations are merged within the
RGB color itself on import, so there's no need to preserve the
original transformations, but that's necessary in the case of scheme
colors.
Slightly modified an existing unit test to check this feature too.
Change-Id: I3a03a56f2b633f283c392e54842b326bd4df316b
LibreOffice is unable to properly import the custom gradient fills
defined in ooxml documents. To prevent data loss, we save the
original gradient fill definition in the shape interopgrabbag and we
write it back to the document on export.
In case the user has changed the fill properties of a shape, the
original fill will be discarded in favor of the new fill.
We have added a new ooxmlexport unit test to test this feature.
We have also added some missing transformations to the methods
getColorTransformationName and getColorTransformationToken in Color
class, and refactored some code in class DrawingML to the method
WriteColor( OUString, Sequence ).
Change-Id: Ie71f89eaa20313561aa9180ea33b76f3fb5e5df6
Color tags like <a:schemeClr> can have children tags that modify the
specified color. These modifications were applied on import time in
the Color object, but they were not preserved.
We added a member to Color object to preserve the unaltered list of
transformations. The method getTransformations() returns that member,
and the methods getColorTransformationName and
getColorTransformationToken were added to transform the tokens into
strings that can be added to an InteropGrabBag and viceversa.
The transformations are added to the Shape InteropGrabBag in the
method Shape::createAndInsert, and they are written back on export
time at DrawingML::WriteStyleProperties.
The data files for some /sd/qa/ unit tests were updated to reflect
the new properties inside the Shape InteropGrabBag.
Change-Id: Ieb164268c3b79f2d9b7ed3a4954b5de3b7a5811c
Cause:
- In altenrate content, Fallback contains only group tag.
Implementation:
- Added export logic in Vml export.
- Added unit test case for vml group.
Change-Id: Ia1c9834950528dc892caea1cb675a7f42165d9ba
Reviewed-on: https://gerrit.libreoffice.org/7276
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Users can select the fill color for a shape among the theme-defined
colors. This results in the following XML:
<wps:spPr>
...
<a:solidFill>
<a:schemeClr val="accent2"/>
</a:solidFill>
...
</wps:spPr>
Now we store both the original fill color and the name of the
theme-defined color, if it exists, on the import phase. They are put
into the InteropGrabBag of the shape with the names
OriginalSolidFillClr and SpPrSolidFillSchemeClr. Additionally, we
needed to to store the decoded theme color inside StyleFillRef.
On the export phase we have to take into account several combinations
of factors:
* If the final color for the shape fill is different from the
original color, we must ignore any theme attributes and write the
new color.
* If the fill color is unchanged and some theme color exists, we must
write the theme color.
* If the fill color is unchanged and no theme color exists, we must
check if the original color matches the style-defined color. If it
does, we must not write any <a:solidFill> tag.
* Otherwise we must write the <a:solidFill> tag with the RGB color.
The method putPropertiesToGrabBag was added to the Shape object for
convenience.
The data files for some /sd/qa/ unit tests were updated to reflect
the new properties inside the Shape InteropGrabBag.
Change-Id: If0915c5442872a8acab0a8a081f60c89c97277bd
Shape style attributes contain the default format for the shape in
case that no direct format is specified for it. This is an example
of the attribute we want to preserve with this patch:
<wps:style>
...
<a:fillRef idx="1">
<a:schemeClr val="accent1"/>
</a:fillRef>
...
</wps:style>
The relevant values in these tags are stored at the maShapeStyleRefs
member in the Shape object. The storage happens at
ShapeStyleContext::onCreateContext which is run when the <a:fillRef>
tag is opened. The ShapeStyleRef object contains the idx value and a
Color object which will contain the inner tag <a:schemeClr>.
The Color object has been modified to store the string value of
schemeClr. The storage happens at ColorValueContext::onStartElement
which is run when the tag <a:schemeClr> is opened.
Later, Shape::createAndInsert is called by the ShapeContextHandler to
create the actual XShape, this happens when the tag <wps:wsp> is
closed. createAndInsert puts idx and schemeClr values into the
InteropGrabBag property of the XShape with the name StyleFillRef.
On export time, when the shape data is written at
ShapeExport::WriteCustomShape, we added a call to
DrawingML::WriteShapeStyle. This method will check the existence of
the InteropGrabBag property in the shape, read the StyleFillRef prop
inside it and output the proper XML to the style definition.
DrawingML::WriteShapeStyle also writes some mock tags into the
<wps:style> because we found that they are compulsory. We will
replace them with the proper data in further patches.
The method putPropertyToGrabBag was added to the Shape object for
convenience.
The data files for some /sd/qa/ unit tests were updated to reflect
the new property StyleFillRef inside the InteropGrabBag.
Change-Id: I5ffa5242852461a1a709a8f169d40f0d7a2c9aa3
Grab-bagged the "editas" attribute of v:group and added UT for
the same
Please verify this fix on MS Office 2007 as it renders the mc:Fallback VML part
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7335
Change-Id: I4e4456997621089967514009005ee775b71d6d69
During export access properties stored during import and write
back those. Currently we just support basic chart data table information
such as border and outline, there are more properties, which are pending.
Conflicts:
chart2/qa/extras/chart2export.cxx
Change-Id: Icbc1245fc829f49833a8c307e029c3dd3dc2e0bd
