Improves patch 1428ec6f4e2bfe0d8654a9ccc713e274e08c6423
When embedding an object into a docx, several things interact:
* The properties in the <o:OLEObject> tag in document.xml
* The ContentType for the file defined in [Content_Types].xml
* The Type of the Relationship defined in document.xml.rels
You need the right combination of those three elements for Word to
properly recognize the embeddings in exported documents.
To know which values must be written, I store some interoperability
information in the import phase in the document grab bag. The
relevant information is the value of the ProgID attribute in the
<o:OLEObject> tag.
I have defined three cases depending on the value of ProgID, but more
could be needed in the future:
* Embedded xlsx sheet.
* Embedded pptx presentation.
* Generic OLE, this should work with embedded odt/ods in combination
with the ProgID attribute stored in the import phase.
Change-Id: I26336cb3fe47bd33e1cef11dd1c7edcf390f2e56
It was crashing, as a quick-fix 43feacd5330b5652b58e8a75a0f41a78ee6ebe1c
(sw: fix build, 2014-02-08) disabled the test. I wanted to fix this
properly today, but it was already working.
Change-Id: Ifbfa82bc907d6c4bd8ec398472f751714c721b09
AlternateContent is used while dealing with shapes, move all those
tests. With this, the original suite has 330 asserts, the new one has
78, and they can run in parallel since
2efee3c632bb8372685bb9f7b07e99b91668d779.
Toplevel 'make' on my machine:
- before: 3m15.237s
- after: 2m40.197s
Change-Id: Id7ac9708e29ae8c6ea7db8aa845de089ed4bdf42
There was a problem if
1)Document is created in MS word
2)then opened in Libreoffice and edited by adding Image and Caption
3)saved back to docx format
4)Attempt to open the DOCX file in Word. Word was crashing.
Problem was if any doc is edited in LO by adding image and Caption LO adds image as anchored inside TextBox.
Which MS word doesn't support(Anchored image inside TextBox).
Verified code changes on both MSWord2007 & MSWord2010 as it was crashing both earlier.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8354
Change-Id: I621d0c5e3acbf9e1fc8514aa70110aa863748ceb
When number of columns in the Index is not specified
by the "\c" switch, then avoid adding the section breaks
explicitly before and after the Index Section and "\c '0'"
in the field identifier string.
Also added UT for the same.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8104
Change-Id: I56826f72beea580d0ac5aef44d4a71fd29b77316
There was a problem that in case of TOC,PAGEREF field tag was not preserved
inside <hyperlink> during Roundtrip.
Reason found, there was no code support to handle PAGEREF in export.
- Added code support in export code to handle PAGEREF.
- Also added <w:webHidden /> tag for PAGEREF
- Earlier pushed code changes was corrupting some documents.
- Verified this patch on large set of Docx containing different combination of hyperlinks.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8048
Change-Id: I2331a33100ed77e15a39ecc6db01b0e696ea62de
The number of columns in an Index is given by the "\c" switch.
During export, added section breaks before and after the Index;
this is to preserve the layout of the round tripped file in MS Office.
Modified MSWordExportBase::NoPageBreakSection so that
an incorrect "nextPage" section break is not exported.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8047
Change-Id: I364e19d6739c4c6a60e3c605044fc1fafd9147d3
Issue :
'Break to Next Page' gets converted to 'Page Break Before'
in RT.
XML diffrenece :
- LO exports <w:br> as <w:pageBreakBefore /> in document.xml
- The page break is written into wrong paragraph.
Implementation :
1] Removed implementation to export <w:pageBreakBefore />.
2] Added a check to write <w:br> in correct paragraph.
3] Modified code to handle SectionBreak() even if Text node
has no string.
It is required when DOCX contains a PageBreak with footer.
4] Written Export Unit Test case.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7891
Change-Id: I237b9c5fdd3083b441f6e81cd8442f458eccf1a0
Problem description:
- If the document contains a hyperlink in footer
that starts with "www" (ex. www.google.com) then
the footer1.xml.rels of the roundtrip file contains
empty Target.
- Since the target is empty, the file get corrupted in MS Office 2007.
Implementation:
- If hyperlink starts with "www" then make bSmart as true.
Change-Id: Ifa2b587d3326152b2d9778bd818fbe68b1cf6410
Reviewed-on: https://gerrit.libreoffice.org/7766
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
The previous fix for this bug only fixed a symptom, this a fix for the
real problem; with the real problem fixed the nCellEnds is unnecessary.
Given that top-level table properties may be put either before or after the
table cells, the only way that works to import tables is to buffer a whole
top-level table row, but currently the buffer is replayed already at the
end of a nested table row.
Fortunately the RTF spec guarantees that \nesttableprops must occur
after the nested table cells of the nested row, so it should be
sufficient to remember the cell properties for the current nested table
row only, in addition to the cell properties for the top-level table row.
With this change, skipping a \nesttableprops destination when there is
a table style turns out to mangle ooo98040-1.rtf badly, so stop doing
that workaround.
RTFDocumentImpl::popState() was copying various buffers up the state
stack which is a clear indication that these shouldn't be members of
RTFParserState in the first place, move them to RTFDocumentImpl.
Change-Id: Ic2d8f7b3e00844b224d61605b405ca651239e5f7
In case the underlying UNO object supports that, which is the case for
Writer. Export was already working before.
Change-Id: I4676c8349ebe1959da004d6e1a024a342da45049
Issue :
- DOCX containing Numbered lists- Strating with
value '0' is not preserved after RT.
- LO exports document with Numbered lists starting
from '1' instead of '0'.
- LO "Import" and "Export" need fixes.
- If LO will imports correctly, export will get
correct value.
Implentation :
- Added code at Import and Export side.
- Added Export Unit test case to check that
<w:start> is not present in numbering.xml
for 0th level.
NOTE : <w:start> is optional. If not mentioned
Numbered lists starts from '0'.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7710
Change-Id: I30910c41fd188f30a1723cf8e07be5ea1cde1be0
see also: SvxLineSpacingItem::PutValue
Move para spacing test from import to export and
remove a test case which tests a part of the same thing.
Change-Id: I96da9f6ac7851bd74e34ab4a6d2a2f3499549a87
unotext: a conversion was missing during the corresponding
SvxLineSpacingItem was filled with "ParaLineSpacing" UNO property.
Change-Id: I02559ed7e8b46150a88eed2bf20afdf084aec47b
Before we started to import the date SDT as a form control, we exported
what is now the HelpText property on the control. So as an initial step,
export that back as plain text, without any formatting.
Change-Id: I569e6690b0c580d8073611b48d610f87974145b3
Regression from fb5ee5c9953635a423d3102b901e409d15800096 (sw: Add
support for different grab bags at PropertyMap., 2013-11-29),
PropertyMap::GetPropertyValues() assumed all XTextRange implementations
support the new property, which is not true for at least editeng.
Change-Id: Ib5657be522d30f203cecbbbae74d6594cef984fb
Added vcl/settings.hxx to all cxx files which require it.
This helps to speed up compilation after changes to the settings.
Conflicts:
sc/source/ui/dbgui/pvlaydlg.cxx
Change-Id: I211a0735c47f72d6879f6f15339355abfe0e3cf4
Reviewed-on: https://gerrit.libreoffice.org/7933
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Most probably this was fixed by 0761f81643a6890457e9ef7d913ab5c88c2593a4
(123792: complete annotations on text ranges feature, 2013-12-19).
Change-Id: Ic712c1a33271081205901ddbf5d629d6f2198126
Translate component of parent shapes' transformation
have to be applied to children when there is no explicit
child transformation.
Note. Export also use this concept.
Change-Id: I51bd3325fb53ee250402326ee361c8f07038ed07
In this document written by "XMLmind XSL-FO Converter" there are less
\cellx than \cell and thus when reading \nestrow/\row a whole buffered
nested table \cell is lost and then subsequently the rest of the nested
table too. Try to fix that by counting both \cell and \cellx and
replaying until the maximum of those.
Cannot count \intbl since we synthesize that in various places.
(regression in LO 3.5)
Change-Id: I3b64ad94af842e076611418589a0c83bd18841c6
