If numbering is detected then (level is > 0) and the number type
is not set, the defult bullet symbol is written. This is not
correct as the default should be SVX_NUM_NUMBER_NONE which should
skip numbering or set it to none. With this change the numbering
is skipped (as in MSO).
Change-Id: I8d08a6325509c7bd6f96f64c8d29e5f3045458ca
Normal charts allow a variety of label placement options, but percent/stacked
charts only allow three variants, and exporting a wrong value would trigger
MS Office to think the file is corrupt.
Change-Id: I8bdc1dc072b29e8df2c506b6b16c61279df12045
If we export a wrong placement value, MS Office will flag the file corrupt and
the loading will fail.
Change-Id: I7ca1239cd390494c1181ecdb3310c5f88bb18f9b
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
Problem Description:
The docx file contains a word art inside a drawing tool.
After RT, nesting of <txbxContent> tag is happening which
is causing the corruption.
Solution: Created a service in util.cxx for checking
few shapetypes for which textbox with content is not
allowed. This check also helps to find that if we are
already inside a DML then we should purely read VML
Information.An existing UT testWordArtWithinDraingtool
was failing. The UT is related to same issue
(word art inside drawing tool) hence changed it
accordingly. Following is the commit id of the
UT-Change-Id: I00e94712e912ad1977fcb65a945fefb927795d77
Change-Id: I7e456c9f6a69af80da443e29eb02a64ba7d59468
Reviewed-on: https://gerrit.libreoffice.org/10229
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Luboš Luňák <l.lunak@collabora.com>
- 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>
I imagine it would be best that the Graphics were delivered pre-swapped in by
higher levels in case there are second level caches or more complex caching
systemed wrapped around it, so warn about it in debug mode but give it a
last-ditch shot anyway. i.e. while the .docx problem should be fixed there
is a report of a very similar .xlsx problem
Change-Id: Ie40ee10fe5cba8ff9c321f47b83e33ee2c1425fd
Values set for docPr name and shape ID attributes in RT file were not valid
as per UTF-8 encoding format and hence was showing RT document as corrupt with
error message "invalid character".
Calling add() function with current parameters is causing issue and
setting invalid values so modified the second parameter which will
set valid values to the specified parameters.
Reviewed on:
https://gerrit.libreoffice.org/9746
Change-Id: I3b48e53adbe5ed844235e596bb98eb396133845a
In general Writer supports having objects inside a TextFrame, Word does
not. It turns out that Word allows having certain shapes inside other
shapes, as long as they are VML-only. So do that for now: if we receive
a shape when we're already inside a shape, then just export it as VML,
not the usual drawingml+VML pair.
Also, blacklist one more VML shape type, where the shape text is already
exported inside <v:textpath>, so no dedicated <v:textbox> is needed.
Change-Id: I5786bd6827eae9756e7c179bb2ef5a5741a91878
CppunitTest_sw_ooxmlsdrexport's testAnchorIdForWP14AndW14 would fail
without this, when "shape with text" is imported as "shape with
textbox".
Change-Id: I8705aee16270aa68416f0c830c429880fc76d85d
We used to write out a custom dash definition all the time, even in case
it was imported from a dash preset. Recognize at least "dash", and write
that on export if the parameters match.
Change-Id: Ifaaec51be9ecf1e7667a8c8f85fbd4fb9636a325
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
As in, for shapes which have textboxes. CppunitTest_sw_ooxmlsdrexport's
testFdo69636 is a reproducer for this problem.
Change-Id: I6575d21b0802ada7f334ca9fbbea796605708ddd
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>
It's possible to write this tag in oox (so it represents the properties
of the shape) or in sw (so it represents the properties of the shape's
textbox). Do the previous, as the textbox is really just a container in
this use case, nothing more.
If we are at it, also fix the default value of <wps:bodyPr>'s l/r/t/bIns
attributes.
Change-Id: I0571b9d8ea7dc0acd5c61f3e28e18400d305eab3
Description:
In RT file the dash length (d) is going out of range,
as after RT the dashing scheme changes to custom dash
which was causing the corruption. Changed code at export,
which will divide the DashLen, DotLen and Distance by
base line width.
Reviewed on:
https://gerrit.libreoffice.org/9559
Change-Id: I0e644b5a2b692a9e717026a14d1f0058199f53b1
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
Problem Description: Docx file containing a chart (line chart / scatter chart)which has used a builtin
marker'x' gets corrupted when we save it in LO.The reason was that while exporting LO was writing the
marker information 'x' as 'X' which MS Word doesn't recognize.‒<c:marker><c:symbol val="X" />. Also
the size of the marker was coming 1 less than the actual value. Ex: if size is 7 then it was being
written as 6.
Solution: During export I have made changes so that now LO writes 'x' in the tag information
‒<c:marker> <c:symbol val="x" />. Now the size of the marker is also being correctly exported.
Change-Id: I26b747f9576625bf3acb941322ae418a0bbc6b64
Reviewed-on: https://gerrit.libreoffice.org/9273
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
If a picture contains some 2D (glow, shadow...) or 3D effect
(rotation, extrusion...), we prevent the importer from transforming
it into a XTextContent so the XShape grab bag is not removed and
the effects are preserved using the existing mechanisms. Added a unit
test for this issue, and modified some existing unit tests to match
the new behaviour.
Change-Id: I3b87069ea208604383a592d34d0a4ceb6b0f9fc7
