| Age | Commit message (Collapse) | Author |
|---|
|
Currently LibreOffice uses the VML fallback, when a docx document has a
wpc:wpc element. This patch implements to use the choice part with the
wpc:wpc element. That is often called 'drawing canvas'.
The patch uses a similar approach as for SmartArt. The drawing canvas is
imported as group shape and for the background an additional rectangular
shape is inserted as first in the children vector.
Not using VML has the advantage, that the custom shape import is used
for preset shapes. VML import produces problems because some properties
are not available in VML or the current VML import has deficits. The
test suite shows examples, what is better without using the VML
fallback. Affected bug reports are e.g. tdf#104671 or tdf#154828.
A drawing canvas must be used in Word for connector shapes. A connector
in Word on the drawing canvas is not written as cxnSp element, but as
ordinary wsp element with additional wps:cNvCnPr child element. The patch
generates a connector in such case.
Unsolved problems:
The path of a curved connector in OOXML is basically incompatible to
the path which LibreOffice generates. This patch uses the default
path for a curved connector. Same is done in import in Impress. Using
the VML fallback had generated a custom shape with the current path
and handles, but the connections to the target shapes were lost.
Export to docx is missing. The drawing canvas is not recreated,
instead a group with the additional background shape is exported. That
is no regression, using VML has produced a group too on export.
I don't know whether XML_graphicFrame can occur in
WordprocessingCanvasContext. At least charts and math equations are
not possible on the drawing canvas in Word.
Import of WordArt shapes does not work. That is not regression. It
works neither in the VML import.
Change-Id: I04bf8407efd1939cdf3137775f8afad420b74014
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156629
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(And some of those dynamic_casts could apparently never evaluate to null, and
the corresponding checks have thus been dropped as being redundant.)
Change-Id: I351d1c9f2894c5a88429ce3c7495f12145664743
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144636
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
PPTShapeGroupContext uses method applyFontRefColor in importExtDrawings
to bring the theme text color to the shape text. The patch copies this
way to ShapeContextHandler, which is used for SmartArt in docx.
Change-Id: Ie0c0453d6a1fd73fbd4b65246aed9570646dc6f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141992
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
|
|
Problem is, that Excel writes a zero size in xdr:xfrm for the SmartArt.
With that the import generates a background size with zero width and
height and no shapes at all in the SmartArt group. The diagram DOM is
imported correctly. The actual size is not known until the row and column
values of the anchor are evaluated.
The idea of this patch is to correct the background size directly and to
repeat the import of drawing.xml when the actual size is known.
I noticed that in import of SmartArt in docx there is a similar problem
that the SmartArt shapes are missing at some point, as can be seen in
ShapeContextHandler::getShape(), about line 428. It uses
ShapeDrawingFragmentHandler to import the shapes. To be able to use that
handler too, I have moved its header file to include.
The solution for docx uses a loop over the vector getExtDrawings(). But I
have not seen a SmartArt case, where more then one element exists in it.
Whether the shape is a diagram, is indirectly tested currently. The
shape has yet no direct method for it.
Change-Id: I9d705ed5bfb2894e9ce740ebf8589e06b4870bed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141571
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
SmartArt import needs the outer size of the diagram for to define a
background shape in the correct size and calculate the size of the
diagram shapes relative to the outer size. The patch passes the values
read from wp:extent in writerfilter to DiagramGraphicDataContext in oox.
Change-Id: Ib39227bc645ac353336bab2c558d041974188f6f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141223
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ia553a24693f2ffc0f580c9869b82f0d01a1a0ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137693
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I336fd329b577b6fa141265d8bc7ce67784bd7306
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133210
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The Style/Theme information is central for re-creating the
Diagram shape representation. Make that data available in
the ModelData classes in svx. With that information, a re-
creation with all needed attributes is possible, e.g. when
the model gets changed (remove/add data entries).
Also some cleanups done.
Change-Id: Icd925c9731891092f1ddd96c8feb165e1f846f4f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132738
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Reorganized and streamlined, use IDiagramHelper as main interface
now also for existing code.
Had to adapt oox::Shape && Diagram handling since there the
import gets handled very different. This ensures that a Diagram
is detected at export and that the same happens for now as before
Had to add a detection that resetting the GrabBag is meant to
disable the Diagam functionality. That is very indirect, but
has to stay for compaibility reasons for now
Change-Id: I620b7d61cd84b5f9dd8ae4dc890ebf70ce779cdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130389
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
|
|
Change-Id: I82405059d900b6605075bf5756f3f0fb99e9002e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129451
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
E.g. OLE formulas inside them broke document load.
Regression from 121cbc250b36290f0f8c7265fea57256dad69553
"tdf#66039 DOCX: import textboxes (with tables, images etc.)
in group shapes".
Note: now embedded VML OLE is loaded in WPG shapes, thanks to
that the ShapeHandler in oox/ has a stack having the start
token inside for each shape.
Change-Id: I973d78ed88c5c83efffd9629061e2a2c6fdd25e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128627
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
In this part, oox module has been modified in order to prepare
for WPG handling during OOXML import. Note: Wpg is the drawingML
equivalent of v:group, supporting text boxes in the group.
1) Added new parameter for WpgContext to support nested
Wpg shapes, and WPS enabled for the WPG member shapes.
2) A bug has fixed, where group member line shape and
connector shapes have wrong positions before in the group.
3) Unit tests had to be modified, and 3 of them disabled
temporarily due to missing Writerfilter implementation (what
will be the next commit)
Now group shapes can have textboxes and the text is imported
for that, but complex content is still missing (this will be
fixed in writerfilter by the next commit).
Known issue: WPG shapes with textboxes in floating table
have issues during import at floating table conversion, so until
this is not fixed this function is disabled for shapes in tables
(will be fixed a follow-up commit later).
Follow-up to commit 19394a924fdc486202ca27e318385287eb0df26f
"tdf#143574 sw: textboxes in group shapes -- part 4".
Change-Id: I71032187697807087bd8f27f7c3a7b052e174bd7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124964
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
See tdf#42949 for motivation
Change-Id: I44e4e3a88067c1c29ce9d563b22741e984b43576
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126964
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: I88831f290e1923db6fb5a733746bfa3bc7fbc7e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122148
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I786096b989daa6004a6527aafbe825b6f0a22d90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120710
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I3ff5333c1e73ca61b0a7339e4b7dcfce211b88e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118207
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
.. in a document.
Shavves 20% off my load time.
Change-Id: I8101b4d229485ebdef0c1f72f856e7cda43559d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118045
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
There is zero chance an extension is using this, because it is so
intimately tired together with the oox and writerfilter interactions.
I'm removing this so I can expose the ShapeContextHandler and then
override it's implementation in a more fashion without jumping through
UNO hoops.
Change-Id: I79ef30247f4642303dfdb92bbf8f6e6226234829
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117996
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia013878ac9c2918d8eaf9aab16b291d8211e708f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110700
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
When importing writerfilter, we change to oox when
importing images. This transition doesn't store any
previous contexts and all instances are reset. The
problem occurs when we have identical images because
the transition erases all caches we have to determine
if an image has already been imported or not, which
causes that we import the same image multiple times
which create unnecessary copies.
This introduces the XGraphicMapper, which can be used
to store the XGraphic for a key and can be transferred
between writerfilter to oox. With this we can remember
which images were already imported and don't create
unnecessary internal copies which decreases memory.
This also includes a test which checks that the import
and export doesn't produce unnecessary copies of
identical images. The test checks that for OOXML, ODF
and MS Binary formats.
Change-Id: I33dc19218c565937fab77e132b3a996c51358b6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103283
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I9ea016adcec334437da45296ee325453347836ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
excluding the UDK headers of course
Change-Id: Iac7ab83d60265f7d362c860776f1de9d5e444ec0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93268
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I95f69d99194f91851b2ef86bebf20006fa32fef3
Reviewed-on: https://gerrit.libreoffice.org/81656
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Id83744fcb90d1bf6e6fe048858f48a4944351494
Reviewed-on: https://gerrit.libreoffice.org/78013
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I89303217fd1141b2cfe248e5e6c0818ba01cf9d9
Reviewed-on: https://gerrit.libreoffice.org/75178
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
It removes diagram content and rebuilds shape tree from diagram markup.
Diagram should appear unchanged - editing will be added in future commits.
Change-Id: I6bfc21956a1a23e55d3c7a74384db71d957d690d
Reviewed-on: https://gerrit.libreoffice.org/71584
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
