Problem : Open docx file which has Text/Picture as water mark.
1. The text is not imported properly also picture water mark is also considered as shape.
2. It writes the watermarks in Document.xml, while it should write in only Header.xml.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8457
Change-Id: Ic988858da25a4cba3ae16e614d920e2e16053a5f
It is stored in the shape grab bag on import and saved back on export.
Defaults to "en-US" if not present in the bag.
Added a check for this attribute in the unit test.
Change-Id: Ib9c74f120628dbfc5e035500424cbad8caed53fe
When saving a date control in a docx document, we were overwriting its
date format with "dd/MM/yyyy" because it's tricky to support all the
possible combinations. Nonetheless, there is no need to overwrite it
if the date in the control remains unchanged during edition.
We preserve the original date of the control, its date format and the
formatted date string on import, and we compare the date in the
control with the original one on export to check if we can write the
old values or we have to re-generate them. Only in case the date has
changed the format will be reset to "dd/MM/yyyy".
We had to add an InteropGrabBag field to the XControlShape because it
didn't have one, unlike other shapes.
Unit tests were modified to check that the dateFormat field is
preserved unchanged.
Change-Id: I01e5c990e90ff190b5a6d7ea3853e049ff24ef0a
Export date controls as ooxml Standard Document Tags (SDT) instead
of replacing them with plain text.
SDT date controls contain the date in ISO format as an attribute of
<date> tag, a custom date format that can be specified by the user
in the <dateFormat> tag and the date formatted in that custom format
in the <w:sdtContent> tag.
The unit test testFormControl from ooxmlexport suite was removed,
it only checked if the date control was exported as text and it
obviously fails now. A new test that checks the values of the
exported control was written instead.
A pair of date format functions were added to datetimeutils.hxx.
TODO: to avoid supporting all the posible custom formats that can be
specified in the <dateFormat> tag, it is forced to dd/mm/yyyy on
export.
Change-Id: I9d1b6f840ee9e133831fdb04ad399fe31bcb2063
Now that the document has a header, better to just test the bottom
margin, as in case there is a header, the top margin has different
semantics in Word and Writer.
Change-Id: I11212965ecd364cdc8a205c3ab3b8b71ed12944b
We convert the dkVert preset to a certain hatch configuration (style,
distance, angle), but when we exported it back, then we didn't recognize
it, and wrote ltVert instead.
Change-Id: I021885496843f5ea5453af3473453bbec50d928f
Otherwise characters unhandled by our OpenSymbol font (like Arabic 0-9
numbers) won't be rendered using an other font, as no other font
provides the symbol charset. Do this in
SwWW8ImplReader::GetFontParams(), where we already have font name ->
font family mappings for a few well-known fonts.
The DOCX filter does the same for quite some time, and that's how Arabic
numbers in text using the Symbol font were rendered, instead of little
rectangles.
Change-Id: Ib794cac19ad7b073e39f3cbd7d4bad3994151c14
When a header/footer substream is parsed, a ParagraphGroup is started,
but not ended; so the properties of the last paragraph in the
header/footer are applied to a paragraph in the body.
The obvious fix to add a call to endParagraphGroup() at the end of w:p
element breaks table cells. So add a call to endParagraphGroup() at
the end of the "hdr"/"ftr" element.
(The problem in the bugdoc became much more visible with commit
ca555c596043c88894b964ac5e21f5a7271d5f3b, but was there before)
Change-Id: Ib054f1882793049b39424c1076ba5d4b319cd027
Problem was Document containing ole object if RoundTripped then after Roundtripping the OLE object was not working.
Which means if doc contains .zip file as ole object then after RoundTripping that .zip object was not getting opened .
Reason found that it was because of missing o:title attribute during RoundTrip for <v:imagedata> inside <v:shape>.
XML file difference :
In document.xml,
Before - <v:shape id="ole_rId2" style="width:72pt;height:40.3pt" o:ole="">
<v:imagedata r:id="rId3" />
</v:shape>
After - <v:shape id="ole_rId2" style="width:72pt;height:40.3pt" o:ole="">
<v:imagedata r:id="rId3" o:title="" />
</v:shape>
Verified that code changes working for other ole objects as well which are: Equations ,Excel Sheet and .zip.
Change-Id: I813de38bcd6e334ce38a661fdfcfa434ef246ed0
Reviewed-on: https://gerrit.libreoffice.org/8458
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Import the "w:space" or the distance between multiple
columns of an Index
Modifies existing UT for the same
Reviewed on:
https://gerrit.libreoffice.org/8444
Change-Id: I6d38e106208524cb22d0b98b0071360865e64bc0
Description:
File corrupt due to the end tag </w:tc> </w:tr> </w:tbl> are missing after roundtrip in header4.xml
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8378
Change-Id: Ib05a50b3b3beca6c744b93360f9341ddcaa1a22a
Added support to grab-bag rels and associated Images for
data[i].xml, and drawing[i].xml.
Added UT for the same
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/8362
Change-Id: I545825f67214f14037ab72b77764a07d575b8b5b
This supports \r flag run-in type index. If \r is specified then we don't
have to write \e flag (separator char).
\h is Alphabetic separator, where indexes are grouped as per starting
character.
Change-Id: I690b29cef3d24b2a71b01f1deef0e418162d71aa
Reviewed-on: https://gerrit.libreoffice.org/8099
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
In general we're overwriting styles on import in case we're not pasting.
But these WW8Num* character styles are in general not from the document,
they are created because Writer needs a character style for each
numbering level to handle what's in the DOC file.
So, in case there is a character style with the same name as our
"character style for numbering" styles, prefer the later ones, as that's
intended most likely.
Change-Id: I675f867722360aca765bb96b0b43ea47deab9847
...because the latter lacks the abs(long) overload in some popular environments,
cf. <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60401> "stdlib.h does not
provide abs(long) overload."
Similarly, stdlib.h lacks the abs(float), abs(double), abs(long double)
overloads compared to cmath there, whose use was apparently intended in
sw/qa/extras/ooxmlexport/ooxmlsdrexport.cxx. Rewrote that to use
CPPUNIT_ASSERT_DOUBLES_EQUAL instead, which revealed that the comparisons need
rather large deltas of .1 resp. .2 (which the original code hid with an
implicit conversion to integral type, thus using an effective delta of 1).
Discovered with -Wabsolute-value ("absolute value function 'abs' given an
argument of type 'long' but has parameter of type 'int' which may cause
truncation of value") recently introduced on Clang trunk towards 3.5.
Change-Id: I4c41575ffdccb2944498b662bd3a53fd510cb0c0
When a document ends with \sect it's possible that a spurious page break
is created. In fact the spurious page break is always created by the
RTF importer, sometimes it is deleted again by
DomainMapper_Impl::RemoveLastParagraph() and sometimes not.
It is created because on the final \sect RTFDocumentImpl::sectBreak()
still calls startSectionGroup(), and the popState() for the \rtf1 group
then calls sectBreak() another time.
To prevent this, do not call startSectionGroup() from sectBreak() but
instead from setNeedSect(), and ensure that it is called as soon as
anything after \sect is read.
One unit test fails because the \page is not handled properly: the
conversion to \skbpage \sect \skbnone is not correct, because the \skb*
keywords are an exception and affect the \sect that precedes them, not
the following one; sending the \skbpage later unfortunately requires
additional cleanup later.
Change-Id: I3c1a3bceb2c8b75bbecdc748170562451ce5f5c3
Improves patch 1428ec6f4e
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 43feacd533
(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
2efee3c632.
Toplevel 'make' on my machine:
- before: 3m15.237s
- after: 2m40.197s
Change-Id: Id7ac9708e29ae8c6ea7db8aa845de089ed4bdf42
