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
...to be able to find problems like 6e0bdf04add338b7d5b29fc7b3fc9f08cfd5e96f
"sal_Bool arg of SetUseImagesInMenus was abused to squeeze '2' through it"
earlier when converting occurrences of sal_Bool to bool.
Restricting this check to function call arguments avoids too much noise while
hopefully still catching all the relevant problems.
(This check partially overlaps the pointertobool check, so implicit conversions
from pointers to bool call arguments will now generate two loplugin warnings,
but that's harmless.)
Change-Id: I0b03b1d1615aaf8bc18e7a84c56fff3ef9903508
Added vcl/settings.hxx to all cxx files which require it.
This helps to speed up compilation after changes to the settings.
Conflicts:
sc/source/ui/dbgui/pvlaydlg.cxx
Change-Id: I211a0735c47f72d6879f6f15339355abfe0e3cf4
Reviewed-on: https://gerrit.libreoffice.org/7933
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Make sure a:cubicBezTo conatins three a:pt elements.
escherex: It seems a cubic bezier curve last point has
a POLY_NORMAL flag and not POLY_CONTROL.
Change-Id: Id6dc2160c7ae171a720e4a1aa9161cef2b3b9413
Issue :
- Number of child nodes required by cubicBexTo should be 3 of type "pt".
While exporting, sometimes the child nodes are less than 3.
The sequence of writing these tags was getting messed up.
Implementation :
- corrected the logic for writing the sequence of cubicBexTo tag.
Change-Id: Ic26db72b2c516276c2e6452a21b4106d6a0a1a80
Reviewed-on: https://gerrit.libreoffice.org/7990
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Issue:
- While exporting the system used to write adjustment values for preset shape type "rect" in document.xml
with the shape guide name(adjustment name) being empty.
- This is not accepted by MS Office. Hence the file was resulting as corrupt.
Implementation:
- The preset shapes are being picked up from GetOOXMLPresetGeometry(), which refers pCustomShapeTypeTranslationTable[] array
for the mapping.
- Most of the shape types have been commented in the pCustomShapeTypeTranslationTable[] array therefore the GetOOXMLPresetGeometry()
defaults the shapetype as rect, whereas the adjustment values are being picked up for the actual shape type(s).
- Uncommenting the commented shape type translations( for instance textInflateTop) in pCustomShapeTypeTranslationTable will
eventually write prst="textInflateTop" under the tag prstGeom which is invalid.
- It should probably go under prstTxWrap.
- In order to avoid the corruption, thought of adding a check before writing the adjustment values. If the shape type is "rect"( which is defaulted
and does not have adjustment values defined in presetShapeDefinitions.xml) then avoid writing the adjustment values under this tag.
Conflicts:
oox/source/export/drawingml.cxx
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7765
Change-Id: I6511e9a3ee0c01962d6e82997705a484161086ef
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
During export access properties stored during import
and write back those. Currently we just support basic chart
display unit information such as builtinunit, there are more
properties ex. custUnit, dispUnitsLbl, extLst.
which are pending.
Conflicts:
chart2/qa/extras/chart2export.cxx
Change-Id: I87e0a8322fc0b0c3df2b8053b7f29fffea611040
Reviewed-on: https://gerrit.libreoffice.org/7722
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
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
So that profiling unit tests (finding out the largets test documents
based on the CSV output on stdout) is possible again.
Change-Id: Ib870d6f424c3219f37715daef5400a0181867be7
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
When the custom shape is not a preset shape then construct a
PolyPolygon and use DrawingML::WritePolyPolygon() to export it.
Change-Id: I6598976a475bfcb92305338af9016e09df4c9456
VmlCommentExporter::StartShape already adds a XML_type to the attribute
list, so we would be exporting the same attribute twice which makes the
xml file invalid. This file could therefore not be imported again.
Change-Id: I2aed2805ea59c15b1f7e60ab9cab10f7a8e81412
Reviewed-on: https://gerrit.libreoffice.org/6980
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Preserve <a:effectRef> tag and its contents from inside shape style
properties tag <wps:style>.
Added some lines to existing unit tests to check for the preservation
of these attributes.
Change-Id: I6e47b228dcc9788a4a2dfe87bd1186d2f04dbeea
Line style and color can be defined by the shape style attributes or
can be directly assigned by the user (and even using a theme color in
the case of color attribute). This patch aims to preserve the
relevant attributes of this feature after a roundtrip.
For style attributes (wps:style/a:lnRef), they are kept and preserved
in the "StyleLnRef" property of the shape InteropGrabBag. To be able
to access to some of them, the methods getLineStyle, getLineJoint and
getLineWidth were added to LineProperties object.
For the line theme color (a:ln/a:solidFill/a:schemeClr), the original
line color and the theme color name are preserved in the properties
"OriginalLnSolidFillClr" and "SpPrLnSolidFillSchemeClr"of the Shape
InteropGrabBag.
On export time, we must check if the user has changed any properties
of the shape line, this is done comparing the new shape attributes
with the original values coming from the style and theme definitions.
In case some of the attributes is different, the new attribute must
be saved overwriting the old one.
The data files for some /sd/qa/ unit tests were updated to reflect
the new properties inside the Shape InteropGrabBag. Besides, an
existing unit test in ooxmlexport was modified to include checks for
the preservation of line style, line theme color and custom line
style that override the style attributes.
Change-Id: Iabb0cef9e3cc433676c201bc296fb7b373839a3f
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
