Age | Commit message (Collapse) | Author |
|
and
coverity#1224996 Uncaught exception
Change-Id: I36ea602a93471d826859bef739c4165117cc4cd9
|
|
Change-Id: I2f8d473ab564c9849963d937690fc48bc04a17b9
|
|
Change-Id: I302cc1e5b164b2ce9999087293b034ec930951af
|
|
Since 1d38cb365543924f9c50014e6b2227e77de1d0c9, "number format" and
"link number format to source" properties are 2 separate properties. Adjust
OOXML import code for that split.
Also, always set axis' number format via NumberFormat property even when it's
a percent format. The axis object doesn't keep a non-percent and percent
number formats separately.
Change-Id: I8667b6f1a78d88cc37d059518919ad1b37f154e1
|
|
Otherwise wrong colors are displayed.
Change-Id: I5d7444100355fdbc5fcd2aaa1c01202ace54312d
|
|
It needs to be set, so that the chart has colors. It was grey before.
The bug was fixed already in aacfd5038d05a02f8b1eade3a5896d3d7e959f3d,
which got pushed sooner, so this commit only changes
the property name from 'INVALID' to 'FillTransparenceGradientName'.
Change-Id: If06899258a4307d583480538338480ba5bb830b9
|
|
regressions around inserted extra enum values
into ShapePropertyId
Change-Id: I06696c8cfe4acc3836723c31d5e714bd7d8439b3
|
|
It seems that inheriting the style from the title for the subtitle is
just wrong.
Change-Id: Icbedf3e934b13514e50a1354552e5d6a8d139095
|
|
We need to pass the role of the data sequence in order to avoid unreliable
guess work when importing static value array.
Also, not all Excel's scatter plots have real numeric X values; some have
textural X values in which case Excel switch to generating 1, 2, 3, ... as
X values. When importing to our chart implementation, using "categories" role
in such cases instead of "values-x" results in a more faithful chart rendering.
Change-Id: If4bc1f650bb024dcd1b1b36537f457fb38404a78
|
|
Change-Id: I92e2d7a3fab0948aea0557cf3cb65d57d48f3f59
|
|
Otherwise a crash ensues when the threaded XML parsing kicks in.
Change-Id: Ic41e5a29bbb860d7b63b70f2f0d8896264d9d53e
|
|
Change-Id: Ibf78e5cd1620f0b61cae030e3870be4a6f87e71d
|
|
Change-Id: I0963c92356f8388ce02fb36e172ad3b2af8ba8f8
|
|
Change-Id: Ie14ba3dcb97f20479a04538748ef2c1c9e6c5dac
|
|
Change-Id: I9de33fdcd8b1ef73d57884033f502ac4a03f63d3
|
|
Change-Id: I8b01bf22e8e3b98ef013b947f617905d558d3554
|
|
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
|
|
Change-Id: Ia391ccc9889a135730f0fead11eb0b6c2f748ec4
|
|
This allows having real shapes (like having rounded corners) and complex
content (like containing a table) at the same time.
WPS shapes are wrappers around drawingML markup in DOCX files, so this
only affects the DOCX import.
Change-Id: Iad1c1c61233be1c17efa1821e680927aa9587215
|
|
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
|
|
Change-Id: Ic63372285fecb6f1be22e92c36cdb6f94733f5c1
|
|
Change-Id: I2b932c9f09a010a4f999707fb6299c392a89550a
Reviewed-on: https://gerrit.libreoffice.org/9806
Reviewed-by: Muthu Subramanian K <muthusuba@gmail.com>
Tested-by: Muthu Subramanian K <muthusuba@gmail.com>
|
|
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
|
|
Change-Id: I6d5a952901648e01904ef5c37f953c517304d31e
|
|
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
|
|
Change-Id: I90deb68ab6a1029cf5df8170676638bf7e3cb469
|
|
Change-Id: I1d428ccd434b7b6f61461ea29447291759c3a7bf
|
|
Change-Id: If5ce403d9a216847532d5a2898e95c9bbde71570
|
|
Change-Id: I4b8a0ebc846ee91530d28821643b3d2f98c0d4f2
|
|
Change-Id: I0cdc7edf851915f7fbc772eb42edd6ec08b09025
|
|
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>
|
|
We don't actually need to check mbAnchorCtr to change
text spacing. This txXfrm workaround works only with rectangles,
because other shapes' text area can be smaller then the shape
size. So add some condition to avoid using it for
other shapes.
Plus fix typos cause regression introduced in:
53c376d35b7223d53e8c9403390afe53d1f69089
Change-Id: I87917b8e0b2bb97ae1bba773e7dda7f81682736f
|
|
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
|
|
Change-Id: I42119f656ca528286fb25d2d36c0af54b7d04a6b
|
|
Change-Id: I8cf274902bb5fda9fa70ab2af9e399db82d85d1d
|
|
fdo75692-2.xlsx and fdo#75692-3.xlsx crash.
Change-Id: I56353e7da1850a49e18d3a570641843600d34b1c
|
|
Change-Id: I692fa22132cd3a722b58de22e3dbb759ff888e5d
|
|
importExtDrawings() must be called as soon as possible,
before parser starts to parse the next shape.
Call it when graphicFrame tag is closed. This tag include
the reference to the SmartArt.
Plus fix up import tests.
Change-Id: I9e8d54c2b1afeb78a1122390dc4982d580c152ae
|
|
Change-Id: I54a51189e1c595841b8b02f3b4436da4a29f1dac
|
|
SmartArt import ignores some fragments during import if
drawing fragment exists, which seems to be not complete.
In this case font style is blank (white) in data (and drawing)
fragment and the real value is defined in the ignored color fragment.
So first make color fragment parsing work, then apply font
color of "node0" style on nodes of the SmartArt.
Actually, it's a workaround, because "node0" style label
is hardcoded, for a proper solution layout fragment should
be parsed too to get the right style label, but
it interferes with the drawing fragment by now.
Change-Id: I7db89176a07eee928563d42d3896fbd02190dfa8
|
|
Text list styles were copied, without proper
copy constructor and operator. It lad to mix
up list styles and so text font.
Change-Id: Iee7a6c0c1f74322fd7b80e41a262849f948e463a
|
|
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
|
|
DOCX shape import normally works by oox creating the shape, then
writerfilter handling the shape text. For drawingML shapes, having shape
text, this a bit more complicated, as there are shape properties after
the shape text as well.
ShapeContextHandler::endFastElement() assumed that shape text is only
possible on css.text.TextFrame shapes: also handle shapes having a
TextBox as well.
sw/qa/extras/ooxmlimport/data/mce-nested.docx is a reproducer for this
problem (group shape missing), when TextBoxes are enabled by default in
oox.
Change-Id: I7a412b31965cf363da0b0c7fcc732741f2037542
|
|
Change-Id: Id3811dbe0cf2510ef6a851804b3886c14eca01b6
|
|
Change-Id: I9e34e14d1266310458bb491259e4bf9880e8a19f
|
|
Change-Id: I4bef14453d076f11066a695bc4a948cea5cfd40b
|
|
In grouped list text area does not cover the whole
shape but just a part of it at the top.
To get the same visual effect modify text distance
attribute.
Change-Id: I32f30d0afbc1975f940c4562ec65f46596e97060
|
|
Change-Id: I171df68539fc41046b706157c04ab1e8cc1e60ca
|