Currently we change shape type to textframe if a shape contains
text. Due to this shape information is not preserved when file
is saved.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7372
Change-Id: I7af3ce29f857d6fa2ceab0350937d91638361e7c
Problem Description:
- When we create the shape with text, rotated it with some angle,
the rotation angle is not preserved after roundtrip.
Implementation:
- Use the FrameInteroGrabBag to preserve the rotation angle.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7367
Change-Id: I8a44e82d21f08ecb221cdbfef73f02a652f2bad3
Grab-bagged the "editas" attribute of v:group and added UT for
the same
Please verify this fix on MS Office 2007 as it renders the mc:Fallback VML part
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7335
Change-Id: I4e4456997621089967514009005ee775b71d6d69
(This is partial fix for this bug)
Implementation :
Provided import & export support for TOC field flag '\b'.
XML file difference :
Before :
<w:instrText>
TOC
</w:instrText>
After :
<w:instrText>
TOC \b "bookmark111" \o "1-9" \o "1-9" \h
</w:instrText>
Conflicts:
sw/inc/tox.hxx
sw/inc/unomap.hxx
sw/inc/unoprnms.hxx
sw/source/core/unocore/unomap.cxx
sw/source/filter/ww8/ww8atr.cxx
writerfilter/source/dmapper/DomainMapper_Impl.cxx
writerfilter/source/dmapper/PropertyIds.cxx
writerfilter/source/dmapper/PropertyIds.hxx
Reviewed on:
https://gerrit.libreoffice.org/7256
Change-Id: I194ba95ca8f25234c0d2a14570fd47eac518b9c5
Issue :
TOC field flag '\w' was not getting preserved after RT.
Implementation :
Provided import & export support for TOC field flag '\w'.
XML file difference :
In document.xml,
Before - <w:instrText>
TOC \o "1-3" \h \z \w
</w:instrText>
After - <w:instrText>
TOC \w \o "1-3" \o "1-3" \h
</w:instrText>
Conflicts:
sw/inc/tox.hxx
sw/inc/unomap.hxx
sw/inc/unoprnms.hxx
sw/source/core/unocore/unomap.cxx
sw/source/filter/ww8/ww8atr.cxx
sw/source/ui/index/cntex.cxx
writerfilter/source/dmapper/DomainMapper_Impl.cxx
writerfilter/source/dmapper/PropertyIds.cxx
writerfilter/source/dmapper/PropertyIds.hxx
Reviewed on:
https://gerrit.libreoffice.org/7238
Change-Id: Ia5d602c6db0b59933d325058ce2d8111e4f03df5
Issue :
TOC field flag '\z' was not getting preserved after RT.
Implementation :
Provided import & export support for TOC field flag '\z'.
XML file difference :
In document.xml,
Before - <w:instrText>
TOC
</w:instrText>
After - <w:instrText>
TOC \z \o "1-3" \o "1-3" \h
</w:instrText>
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
writerfilter/source/dmapper/PropertyIds.cxx
writerfilter/source/dmapper/PropertyIds.hxx
Reviewed on:
https://gerrit.libreoffice.org/7217
Change-Id: I84f90a722c7afbdf626db2cc60c4e73580891d36
(This is partial fix for this bug includes flag 'f' processing)
Issue description:
Export logic for all TOC field flags was enclosed inside
if( nsSwTOXElement::TOX_MARK & pTOX->GetCreateType() ) in ww8atr.cxx,
which gets true for 'f' flag, this was the reason if there is 'f' flag
present in original doc then only other flags like \o \h used to come after RoundTrip.
Added Unit test case to verify even if there is no 'f' flag in original doc,other flags
eg. \h is getting preserved after RT.
Conflicts:
sw/source/filter/ww8/ww8atr.cxx
Reviewed on:
https://gerrit.libreoffice.org/7203
Change-Id: I29d22b363cc91ae5fabffca959786134bf1ba1cc
(This is partial fix for this bug)
Description:
TOC flag field '\o' exported twice after roundtrip because the export logic for '\o' is repeated in ww8atr.cxx.
XML file difference
In document.xml
Before :
<w:instrText>
TOC \o "1-3" \o "1-3" \h
</w:instrText>
After :
<w:instrText>
TOC \o "1-3" \h
</w:instrText>
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7206
Change-Id: I136744927b8d5a48869a2bfc87278bede697c655
As the bug talks about issues in custom styles, now they're tested too.
Change-Id: I5f727718ec3591e29c44c49750a7c7a0841a8c61
Reviewed-on: https://gerrit.libreoffice.org/7373
Reviewed-by: Marcos Souza <marcos.souza.org@gmail.com>
Tested-by: Marcos Souza <marcos.souza.org@gmail.com>
Issue :
- When we have overlapping tables the first table gets
exported as a table and the second table gets exported
as a DML/VML shape.
- While exporting, the system starts with the table row &
the cell, within which it starts exporting the overlapped
table, while doing so the previous table attributes were
being referred since the variable was shared.
Implementation:
- Save and reset the table related attributes before
calling the WriteDMLTextFrame & writeVMLTextFrame
functions.
- Restore the table attributes for further processing after
having written the shape.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7364
Change-Id: I0052a08c74ffbbebd3eb91a7075a43a4c225b670
Issue:
1] Document containing SmartArt inside <wp:anchor>
tag gets saved with <wp:inline>, due to which
value of attribute "id" of <wp:docPr> gets
incorrectly written.
Which was causing the corruption.
2] LO was exporting SmartArt inside <wp:inline>
bydefault. Hence "ids" of <wp:inline> and <wp:anchor>
were same for value 1 and document gets corrupt.
Implementation:
1] Added code to export SmartArt inside <wp:anchor>
in DocxSdrExport::writeDiagram().
2] Added export Unit test.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7292
Change-Id: I5b2efcba030d1736203cf4571d8498fd87600d79
Cause:
- Extra space gets added in document due to default <rPr>
is getting removed from <pPr>.
Implementation:
- The 'rPr' inside 'pPr' means the properties of the 'paragraph marker'.
- In that case - the paragraph marker will have different formatting then
the rest of the runs in the paragraph.
- Added default rpr tag in pPr.
Reviewed on:
https://gerrit.libreoffice.org/7216
Change-Id: I5a1a1f251ccc5b555ea6bf3bac3e69af8b2b69b5
Plcfbkl contains only character positions. The Plcfbkf is that one
which contains additional informations.
Change-Id: I9bd8eec5c8e64d9d757764dae51bcb866456cdc9
- Bitmap url was not stored propertly for textframes.
- Exported background image fill for text box properly.
- Added unit test.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7259
Change-Id: I1fbab24b2a83b22be04fd6950c80ddf274436738
Commit 330b860205c7ba69dd6603f65324d0f89ad9cd5f (fdo#68787 DOCX import:
handle when w:separator is missing for footnotes, 2013-09-04) disabled
footnote separator by default in dmapper, as the OOXML tokenizer always
provided a uFtnEdnSep in case a separator was wanted.
Let the RTF tokenizer do the same, this way we're in sync with Word
again: if RTF_CHFTNSEP is in RTF_FTNSEP, then we show the separator,
otherwise we don't.
Change-Id: I74b46c5d71227682e093695336dc9eb6fde22121
It seems that in Word, a zero parent transformation, like:
<a:chOff x="0" y="0"/>
<a:chExt cx="0" cy="0"/>
means the child shapes will have an absolute position / size. We
actually use this feature in the exporter, but so far the importer
didn't handle this.
Change-Id: I250784a3dddd23649e391b548fc128dfdf153614
When makeFieldBookmark() method is called with
ODF_COMMENTRANGE it will ignore the added field name and
generate an own one. We have to set the name of the
SwPostItField to this generated name so these two names will match.
Note: lTagBkmk is only an identifier but not the exported name
of the fieldmark so we don't need to stick to use it as
a name.
Change-Id: I499abdcce1be0563c308bcf9f5c0a959a07f858b
The problem was that due to setting it to 18 in oox, the rectangle
didn't inherit the default 11 from the document.
Change-Id: I05c3b9c1d64eec58695e2039651a5f015df1f9e4
Added Import and Export Uts for the same
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7207
Change-Id: I966b3d268dd407aa05823e29fe1da4d097091265
So far adjustment names were either taken from the document model, or in
case there the name was empty, either "adj" was used (in case of a
single adjustment) or "adj1", "adj2", etc.
The problem is that there is no consistency here, e.g. this behavior was
correct for "cube" (single adjustment is called "adj"), but not for
"bentConnector3", where the single argument is called "adj1".
Instead of trying to guess or build a long list manually, use the new
ooxDrawingMLGetAdjNames() to write the correct names.
Change-Id: I3d609975d89c7c79f4a70c7a739cab8e01f9667f
"pictureFrame" is not a valid drawingML shape type, VML export used to
write just "rect", by removing an explicit entry for
ESCHER_ShpInst_PictureFrame we now do the same.
Change-Id: I57683b7f5f80bfef8c3b6fb9ae9f33e4599a7eb2
This was the last shape type that unconditionally wrote XML_sp for the
shape element, which is invalid for DOCX.
Change-Id: I3a6f8e6fd8ebbe663dce9ed4453396c3ec91c38a
This is a unit-test added to complement the patch that added support
for the preservation of 'Track Changes - Inserted Paragraph Mark' from
a DOCX file.
Change-Id: I21e67b3ed8c98e8aba2c633dc6a549786ae44322
Reviewed-on: https://gerrit.libreoffice.org/7241
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This is a unit-test added to complement the patch that added support
for the preservation of 'Track Changes - Deleted Paragraph Mark' from
a DOCX file.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7240
Change-Id: I161bcd90ec891fad60dfd5b7c77edddfd90b7fa8
And not the other way around, how
24ee3df385cf2aa95cd888581c84fdf90cc682dc (RTF import: fix priority
handling of shpz vs dhgt, 2012-04-10) did, this time with a reproducer.
Change-Id: I9412341c6b35ca2760e4490a18f11bc6a0e0b78a
These describe an explicit horizontal merge, that is not something Word
itself creates, but it turns out the Calc RTF export does.
Change-Id: I1b6ec10bb8e8bd40e24791ccc96f2f066dd0d5d5
This was only available in experimental mode previously. Also note that
export of shapes (including group shapes) was already enabled
previously, this commit just enables the same for Writer Text Frames.
Change-Id: I53e7f3fac84328cea316a9811ecd5eecec79b23d
The theme fill attribute and the original fill color are saved to the
paragraph grab bag during the import.
On export, the original fill color and the current one are compared
to know if the user has changed the fill color during the edition. In
that case, the theme fill attribute and the original color are
dropped.
Some methods related to the grab bag management were added to
CellColorHandler for convenience.
Added a unit test for this attribute.
Change-Id: Ic0514ce1d2f290fb0aef5ed86327c1f03f31f20c
