Word stores compatibility mode and additional compatibility
settings (like enableOpenTypeFeatures) in w:compatSetting. This
needs to be preserved as well.
Change-Id: I40895cc00952b7c3799edff0bf7f4328106305a1
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
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
i.e. those which are providing the default value explicitly
(cherry picked from commit 5a15ef3da683566d7bd443f96eeec3a9a3f70aeb)
Conflicts:
writerfilter/source/dmapper/DomainMapper.cxx
writerfilter/source/dmapper/PropertyMap.cxx
Change-Id: Ib8721f2fce060d26ee75b0515b3bf62a603fd40c
We're not pushing these properties to the parser stack (as the old name
suggested), but sending them to dmapper.
Change-Id: I9725b7b92e653064c18d723f48a350ebc8e740c8
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
Inside DomainMapper::graphicZOrderHelper() this is offset by 0x40 so
whatever that cast does, it's doing it wrong.
Change-Id: Ie48467c12828137a521cba47c2e04cac65201d1d
