For one, replace m_nLastRangeStartPos with a map, so that we can keep
track of the start positions when multiple comments are open at the same
time.
For another, sort PlcfAtnBkl and PlcfAtnBkf by position as Word requires
it; with non-nested comments such explicit sorting wasn't necessary.
This also required building two maps, so that we can know what
PlcfAtnBkl index to reference in PlcfandRef, and what PlcfAtnBkf index
to reference in PlcfAtnBkl after sorting.
Change-Id: I2d7096b0c68a6b327efc4b5593ac96cdd297b3bd
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
Issue :
File containing Shape with text inside it having Line style as
Dash type is not getting preserved after RT.
Implementation :
1] Added XML element <a:prstDash> with attribute val="dash".
2] Written Export Unit test case.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7572
Change-Id: I27ca9f8786426a224b32dbd2aeabc40be244c9db
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
Issue:
The <wp:align> is missing after roundtrip
XML Difference:
Original:
<wp:positionH relativeFrom="page">
<wp:align>
center
</wp:align>
</wp:positionH>
Roundtrip:
<wp:positionH relativeFrom="page">
<wp:posOffset>
0
</wp:posOffset>
</wp:positionH>
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7571
Change-Id: I3c8ef2f0ee3dd84a23fab197ab95f152b850067e
The file contains a table with 3 columns. The girdcols
are as follows: {1210, 1331, 1210}, whereas the
individual cells have {1210, 400, 1210}.
The table column separators were taken from the grid while
the table width was calculated as 2820 from cells
instead of 3751 from the grid.
Hence the table width reduced after export to DOCX
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7540
Change-Id: I2c590ad6b5ec9fe3e8559971ca8cfa69c5343f47
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>
Commit 734cf8395 introduced a unit test, which depends on a Calibri
metric-compatible font. So this adds a fonctconfig based check to
configure and just runs this test, if configure finds a correctly
mapped font.
Reviewed on:
https://gerrit.libreoffice.org/7596
Change-Id: I5255a4366684b115d88adca78ab2002864b63766
Issue :
- The margins for distL & distR were getting exported as a negative
value viz ( distL="-635" distR="-635" ).
- While setting the default frame properties the values for distL
& distR were getting defaulted to -1, this value was further
considered while exporting for calculations hence the value
-635 used to appear.
Implementation :
- according to Ecma 20.4.3.6 the values of distL & distR should
be positive.
- Added a condition to check the negativity of the value while
setting it to default.
- observed that horizontal orientation values were being populated
to distT & distB( top & bottom margin respectively) and
vertical orientation values were being populated to distL & distR
(Left and right margin respectively). The values should have been
vice versa. Corrected the same.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7501
Change-Id: I056e5845b64cd755429297899eeb972f6009efec
DOCX has two defaults: there can be default paragraph/run properties,
and also a paragraph/character style can be marked as default.
In this case the problem was that no doc-level default was specified,
but the default para style set a char height, and shape text is expected
to inherit that. Fix this by setting doc-level font size to default para
style, in case it's not set yet -- that matches what the binary import
does.
Also, adjust the export side, so that these duplicated default font size
is not written on export.
Change-Id: I63b368e7704142171d58f48d08052ac7616ab166
There was a problem for some documents(containing table on page spanning across multiple pages
& pages having different Header-Footer type), during export Invalid sectPr was getting added
because of wrong condition check in the code.
Because of this:
1)Table row data was getting displayed twice after RT.
2)Increased number of pages after RT.
3)Header & footer were also divided into sections (like: Header-Section1 Footer-Section1 & Header-Section2 Footer-Section2).
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7440
Change-Id: I6c07e47321353e84af306c6285702852303ccee0
In case of DOCX, the DOCX wrapper around the drawingML fragment already
contains the real position of the shape (which talks about paragraphs
and other concepts which are unavailable in a spreadsheet /
presentation), and the inner position should be 0, otherwise the shape
is shifted towards the bottom right corner.
Note that this only affects drawinglayer shapes in DOCX, Writer pictures
are handled in sw, and those always had a 0,0 position in the inner
drawingML fragment.
Change-Id: I582b1ae64387b50ffb051e1f5017eab0e5d5ab34
I'm not exactly sure why existing code didn't do this implicitly, but at
least this improves the situation.
Change-Id: Id2bb169c513827b7ef48640dc88fad90a83d2bee
The table manager can work with more table simultaneously
and so m_aCellWidths contains more table's properties.Only one
item of it belongs to the current table (getCurrentCellwidths).
Regression from 74c5ed19f430327988194cdcd6bdff09591a93fa
Change-Id: I93efac0c004af1b2524c955ffb20c3ecd74a2920
Issue :
DOCX contatining TOC Code field '\u' was not getting
preserved after RT.
Implementation :
1] Provided import & export support for TOC field flag '\u'.
2] Written export Unit Test for code field '\u'.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7202
Change-Id: I43872c7db21c25e0586bf874d5bb0c9115ab76af
This tests checks that the shape style attribute for fill color is
preserved, that the theme attibute for shape fill is preserved too
and that the interaction between them and direct assignment of some
color works properly.
Change-Id: Ia934c46731ed38be14ed851e083d0ed6fc151b01
This matches the behavior of the WW8 import and gives us the required
text wrapping when the shape text doesn't fit in a single line.
Change-Id: I32a13516503620344d313593834be29a3dc9f726
The VML concept is that the height / width of a textbox is absolute, and
border distances only affect the position of the shape text, not the
size of it. OTOH, when we set the Text*Distance UNO properties on a
textbox, the size may change. Make sure that during VML import setting
those properties doesn't change the size.
Change-Id: I53b328b66572fc05027be344869bc1a78d855558
It turns out that this table contained entries which are not valid
drawingML preset shape names.
Invalid entries are now either have a valid name instead (based on the
oox/source/export/preset-definitions-to-shape-types.pl mapping, which
already tries to map VML shape ID's to drawingML preset strings), or in
case I found no mapping there, the entry is now simply commented out.
It's still better to fall back to export a shape as a rectangle than
corrupting the whole document.
Change-Id: Ic2d8926e5819f3312aaca55d50a1492332e52a9d
This is a unit-test added to complement the patch that added support
for the preservation of 'Track Changes - Paragraph Properties Changed'
from a DOCX file.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7401
Change-Id: Ic81a5ac9ee369ae0f1d2f8d1a1fe54ea5e6b7402
