Also extend testcase: I made sure that the new version fails without
this fix and without the fix from
48b5b7641d0df960558082e8948da8598f801264 as well.
Change-Id: If33aa6d33cdc287620c12b84ad3f50279568bc8d
- In given file header contains oleobject.
- Relationship for oleobject was wrongly exported into
document.xml.rels file.
- serializer for writeoleobject was wrong.
- fixed issue and added UT For it.
Change-Id: I03ab3a14def62b8061f58f7001684e0e945ad74a
Reviewed-on: https://gerrit.libreoffice.org/8534
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
SvxBoxItem::nLeftDist is unsigned; the bugdoc sets a very large value
due to wrap-around which causes the table content not to be displayed.
DomainMapperTableHandler::endTableGetTableStyle() tweaks the
rInfo.nLeftBorderDistance by adding half the border line width to it,
which makes it positive; at that point the value has already been used
to init table::TableBorderDistances, so move that downward so it gets
the positive value too.
Change-Id: Ied2331b93f2e95845d7e8b2cc06e89e1ab24296e
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
