Section properties are not imported if the section starts with a table for DOCX,
and also for a few RTF files with combination of tables and section breaks.
SwXBodyText::createTextCursorByRange is not able to find the start of section and hence
section properties are not applied.
As a workaround added an empty paragraph at the beginning of every section
which has the the first element as a table. And then removed it when the
section ends ( DomainMapper::lcl_endSectionGroup is called).
Also handled to add the paragraph earlier, if there is a bookmark
so that the bookmark is not attached to the dummy paragraph.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/9097
Change-Id: I717ba40e22b055d974bc83d4414aeb2945e16d26
Reused most of the code of outerShdw effect. Modified an existing
unit test to add a check for innerShdw.
Change-Id: Ifdd77850bfd3b5fa250594469455b1b66c338611
Docx's w:gridBefore means that there should be this given space in the table
grid before any cells come. But writer requires tables to be rectangular, so
the space needs to be faked using cells without border. So far so good, but
now reality in the form of the retarded overdesigned writerfilter comes.
The internal representation of table data (and not just one actually) is
pretty non-obvious and hard to modify, seems to be modelled just to follow
the parser data the way it comes. Moreover dmapper gets notified of w:gridBefore
only after cells in the row have been already processed. So after futile attempts
to add the fake cells somehow in dmapper I've eventually given up and hacked up
input handling to fake input as if the fake cells were actually there (which
was tedious to find out as well, but at least it's reasonably doable).
Change-Id: I7107e13f28dd3f7093688782f64238167cead76f
The goal is preserving the shadow effect with all its attributes using
the shape grab bag. This is the relevant piece of XML in the document:
<a:effectLst>
<a:outerShdw blurRad="50800" dist="38100"
dir="2700000" algn="tl" rotWithShape="0">
<a:schemeClr val="accent1">
<a:alpha val="40000" />
</a:schemeClr>
</a:outerShdw>
</a:effectLst>
In first place, we added members to the structure EffectProperties to
store the effect name and attributes. Later, when we create the shape,
we add them to the shape grab bag together with the shadow color (if
it is a theme color we store its name and transformations like in
other cases). Finally, we read back all these data from the shape grab
bag and write them back to the document.
I added a unit test for this shape property.
Change-Id: Idda2d5e2970cb8563e2ed13a84b2fa2d4b99aa70
- Textbox run character properties are change after roundtrip
- Italic case was not handled in textcharacter properties
Reviewed on:
https://gerrit.libreoffice.org/9096
Change-Id: Ia38fcadce489ef0bfffb9bda402d13058cf6129a
In case the URL text has multiple portions, then MSWordExportBase
generates multiple URL's anyway, and this helps to avoid loosing some
direct formatting of the remaining portions of the paragraph.
Change-Id: Ifd72741de610ce69b9ae0978aa8f9a532a3aeed2
Previously only the number of nested sprms / attributes was compared.
With this, the font of the bugdoc is correctly Arial, not Times.
Change-Id: I351de414b6734336b31c1334dbd2349072f16002
Added support for linked textboxes for docx interoperability.
Reviewed on:
https://gerrit.libreoffice.org/9092
Change-Id: I7db4f5a1783afff53c64908d182788b262f5e863
The test document has 4 pages which only contain frames, first 3 pages
(sections) have <p> block with <framePr> and another <p> with just <sectPr>,
and the second paragraph would be removed, thus there would be no nodes on which
to actually set the page style and they would be set on nodes for the previous
page, overwriting its page style. The last page does not have its own <p>
at all, so it needs to be faked.
The changes in finishParagraph() are because of e.g. the comments-nested.odt
sw test, which there causes exception because of unknown property ParaStyleName
(comments do not use those it seems) and the code is skipped over (which
is probably a bug on its own, but it's unrelated to this change otherwise).
Change-Id: I9d37f992407a9b649c710d2a031ec4447fb11771
Regression from a48e2fd9049797110b3b2505c363557284987ca8 (fdo#44736 -
convert RTFSprms to a copy-on-write structure., 2012-12-07)
Change-Id: I2538f440e29cef6d40db2ea914e4afcbfe411890
Description:
For pStyle = 'NumberedList1', iLvl and numId was not preserved.
These tags needs to be preserved under numPr in document.xml
These tags are preserved now.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Change-Id: Ib6734c9ae55bd72d4fbc0f6d6cae85764ac1a244
Reviewed-on: https://gerrit.libreoffice.org/7767
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Problem description:
For the images who has the "Text wrapping" property set as Behind Text
is not preserved after saving the file in DOCX format using LO.
Reviewed on:
https://gerrit.libreoffice.org/9065
Change-Id: Ic8555103909c0f1ed1cb58fba4dc2ef2f84cc9dd
1. Open the attached file in LO which has images [.TIF] format
2. Save the document as DOCX
3. Open the saved document in MS-Office or extract the content of the saved docx file.
In [Content_Types].xml , .tif extension is changed to .tiff.
Change-Id: I73baea9ad6cd991b04d47e23865b77432127a510
Reviewed-on: https://gerrit.libreoffice.org/9010
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Description: There was a problem for some documents, that when opened in LibreOffice
extra image was getting added to the first page of the doc and same could be noticed
even in RoundTripped doc.
The root cause was if picture bullet is added to the doc and there is no <w:lvlPicBulletId> tag
in <w:lvl> of <w:abstractNum> then removal of extra added graphic object from document body was
getting missed because currently that is handled in ListsManager::lcl_sprm() inside "case NS_ooxml::LN_CT_Lvl_lvlPicBulletId".
Checking if there is any remaining item in m_aNumPicBullets when LO hits the ListsManager destructor.
If there is any calling dispose() for all of them.
Change-Id: Ibfc3c93b68ff7d6ef0909fe789dda6db67ac11e2
Reviewed-on: https://gerrit.libreoffice.org/8940
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This patch fixes an error in commit
c6ff03f37a6898f50a5ca07152168fb4fe911e05.
And now that fdo#75722 is fixed, I completed the existing unit test
for this bug with absolute position checks.
Change-Id: I76b4fa046db9b946fd23194e91686ffa4fcb5362
The DML importer used a tranformation matrix to rotate the shape, but
I replaced it with the same code that's being used in the VML importer
in which the position is correctly set.
I've noticed that I cannot use that code in all cases thanks to the
existing unit tests; that's why I added the bUseRotationTransform. In
case it is set to true the existing transformation matrix rotation is
used.
Finally I added a unit test for this case.
Change-Id: I260c14b42d169def786e15484e4ecb1d8e8584e4
Description :
In StyleSheetTable.cxx, while setting the property "ParaInteropGrabBag" throws an exception.
Hence rest of the properties are not set.
Implimentation :
Skip that property so that rest of the properties will not be lost.
Change-Id: Id488de71bc5f893a7401420d9e63e4405b90f760
Reviewed-on: https://gerrit.libreoffice.org/8902
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
There are two issue related to table in the saved(exported) file
- the table alignment in saved file is "left" instead of "center"
- the table width type in properties is "auto" instead of "dxa"
In the issue file alignment was specified in w:tblpXSpec="center"
and so were missed at import. Added support to fetch
HORI_ORIENT from frame properties if its not set in Table Properties
The ::GetTablePageSize returns 0 if the table width is FIXED.
Modified it to return the tableWidth in such case.
Conflicts:
writerfilter/source/dmapper/DomainMapperTableHandler.cxx
Reviewed on:
https://gerrit.libreoffice.org/8846
Change-Id: I02a3af5e9d8ef3746c4d6bec0a07a24e01cc12a4
The Writer 'Heading 3' paragraph style is gray by default, but (just
like in case of DOCX) that shouldn't have any influence on the RTF
import result.
Fix this by moving the compat setting from the DOCX filter
implementation to the common dmapper.
Change-Id: I86c7cf1a66f82b438ce8379467773a88c9e229af
The document containing a custom table is getting crashed.
In the document the user has created his own costume table styles and
in the created custom table style the user has set repeat first row as header property.
The corresponding tag for this property is 'tblHeader'
LO was adding this property as a part of cellProperties in DomainMapperTableHandler.cxx.
But it is a part of a Row Property. That is why there was a crash @ open.
In DomainMapperTableHandler.cxx : 'endTableGetCellProperties' tblHeader property is removed from
style as it is not allowed for a cell.
Change-Id: I83cd369aa4497ec3f4b567174f23ddee9be2864e
Reviewed-on: https://gerrit.libreoffice.org/8848
Tested-by: David Tardon <dtardon@redhat.com>
Reviewed-by: David Tardon <dtardon@redhat.com>
Compared to 4c8d29f4f26bfa30689b2b98414fe874225b9a2e, we do not have to
provide 0 to mark the end.
Change-Id: I3b9a3de61df48caf271cb06b27cf9cfa174dc4ed
Problem Description:
- In LibreOffice, the index field flag '\f' was not
getting preserved after roundtrip as there was no
support for it.
- '\f' field flag is used for Specific Entry Type.
ex. In our case it is "Syn"
Implementation:
- Provided import & export support for Index field flag '\f'
and added UT for the same.
Change-Id: I97c2456dd73c8bdf89ab105f8cac71bf7e2ad164
Reviewed-on: https://gerrit.libreoffice.org/8839
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This test exercises the *export* component of recent work to add support
for full colour borders in .doc import/export.
Change-Id: I2da0b8b488e399d0cd4791678fac6e1c85921c2c
Reviewed-on: https://gerrit.libreoffice.org/8887
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
- Earlier the table width was compared with the text area to decide if the
fly has to be created for the floating table.
- In most of the cases such floating tables were the ones which did not have
any text around them and not importing such tables as fly made sense.
- But there are some scenarios where in the floating tables have width
greater than the text area but are positioned in a way such that they begin
before left margin and end before the right margin moreover they appear to be
really floating (unlike in first scenario) as they have text around them since
there is still room for the text.
- Handled this scenario and added a UT.
Reviewed on:
https://gerrit.libreoffice.org/8840
Change-Id: I7ea25e04ed7c6315e4e4fe4b67badf451c30cd0c
Additionally add loading of HTML document and parsing the document
with libxml - to be able to assert with xpath expression.
Change-Id: I7c62082a124c3705626cd76c8a4cdabc16372399
