When we have a style to import and the name is already taken, we reuse
the style (we can't use replaceByName(), it only works with user-defined
styles). If that happens, reset non-default properties of it, so the
result will be what was in the file, not a merge of Writer defaults and
what was in the file.
Change-Id: Ifb1098f78254a061b11fd6c6d2a2fa8d85a00d60
<vmiklos> sberg: the comment says that it was 2, so unless you're interested in
debugging it, i would just lower the barrier (423 -> 369)
Change-Id: I0269eab4eee594c4d7aad1c710ed389443208bc4
- There is pagebreak in file and footer has nested table.
- While exporting LO write section break instead of PAGE_BREAK.
- Due to this it was writing two sections in file and same footer
for both sections.
- This was causing wrong table depth values due to this it was crashing
while writing table.
- So in MSWordExportBase::OutputSectionBreaks if next node has
RES_BREAK(page break) then bNewPageDesc value should be false.
Change-Id: I2ccc4e48a26253716253a7280a244f06e172770a
Reviewed-on: https://gerrit.libreoffice.org/9568
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Word will reject Shift-JIS following \loch, but apparently OOo could read
and (worse) write such documents, so accept Shift-JIS regardless of run
charset type.
Change-Id: Ib181956e9f218548a52037dd76fa1d3ecdc006bd
This is a variable-length encoding, and the second byte may be a RTF
syntax character like \, {, }.
Change-Id: I813ccafda18388af3bf05eb7ce9a0253c627b1c4
There is a lot more to test here, but for now just test that we can have
tables and rounded corners at the same time.
Change-Id: Ia9a4877202d1d040209f49a428b83633c58fc7c7
The problem was that right after the import, the document wasn't marked
as modified, but as layout settled, it got marked as modified.
Given that we already have code to avoid modification when updating the
replacement image, do something similar here: when setting the view
area, make sure the embedded object's component is not marked as
modified.
Change-Id: I88a42829ec48db54178553661863a571cd2a268b
Issue :
- In styles.xml, beforeAutospacing property was set to true.
- In code LO grab bags AustoSpacing property using "ParaInteropGrabBag".
- But ParaInteropGrabBag had only an entry for direct paragraph properties,
not paragraph styles.
- Hence while importing AustoSpacing property from styles.xml, LO was throwing exception
as "Some style properties could not be set: Unknown property: ParaInteropGrabBag".
Implementation :
- Added "ParaInteropGarbBag" entry for Paragraph styles in
sw/source/core/unocore/unomap.cxx
- Removed code from StyleSheetTable::ApplyStyleSheets() as it was previously added to
"Ignore" the AutoSpacing property.
The code was previously added beacuse due to AutpSpacing in styles.xml,
LO was throwing an exception and this was causing unhandling of properties after AutoSpacing.
So to prevent unhandling of other properties due to AutoSpacing property, a check was added to
"Ignore" AutoSpacing, thus enabling handling of properties after AutoSpacing.
Please refer to : https://gerrit.libreoffice.org/#/c/8902/
But as now we have to "Preserve AutoSpacing" this check needs to be removed in order to set
it in StyelSheetTable.cxx.
- Added Export Unit test case
Change-Id: I6748f97befcdf40643e75388766e05740290306b
Reviewed-on: https://gerrit.libreoffice.org/9561
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Description:
Writer getting Hang while opening document because of loop in layout.
Root cause: For Documents containing table with direct formatting for
Para line spacing along with style w:type="table" in style.xml LO was
erasing PROP_PARA_LINE_SPACING Prop from pAllCellProps in
DomainMapperTableHandler::endTableGetCellProperties(). But for
Documents without direct formatting for Para line spacing this deletion
was causing problem, as after deletion there is no formatting available
to apply.
To fix this checking whether there is a Direct formatting available for
table, if Yes then proceed with this deletion logic.
Change-Id: Ibaf51ebd1aca93eff44a9edfbe8fa13832ab2b70
Signed-off-by: Michael Stahl <mstahl@redhat.com>
A vert orient position was already handled in case a floating table was
imported as a TextFrame, but in case we didn't do that, the vert orient
position was simply lost.
Fix this by importing it as the upper margin of the table (assuming that
the position is relative from the anchor position).
Change-Id: I3e96f3068605fd6313dfb3e55483e1bce6c063a5
Any DOCX export test that is related to shapes should go to the sdr
suite to be able to execute in parallel.
Change-Id: I719cd6eda973c5daa1f11bb0e1f57bbacab9f812
When we do the export of the file, In the footnotes.xml,
the w14 namespaces were not being added.
This issue exists for EndNotes as well.
Change-Id: I6494bbf1beaa0666743d9c1bb85a64f8bda20398
Reviewed-on: https://gerrit.libreoffice.org/9439
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
...result still unsigned at sw/source/filter/ww8/docxsdrexport.cxx(441)
Just use SAL_{MAX,MIN}_INT32 (change -2147483648 to (-2147483647-1)) which fixes this warning for MSVC.
Change-Id: Ia039906602d3b00193a364bddb81626afa928f2d
If the old width was that small, then something larger should be also
fine. (Seen 564 instead of 423.)
Change-Id: Ife0fd4a55738268cdc1691b90e28b51adba829ef
The negative crop values were imported as large positive values, which
caused the image to be rendered with 1 pixel width after commit
2e5167528f.
Change-Id: I0e01b9d9a05d90e868699832085a06ba5aab7e54
782adba4d4 discards unneeded headers/footers,
but only the text, not e.g. frames or fields. The test document therefore
ends up with a frame with a page number inside the body text, because the text
in the footer it should be anchored to was discarded. This commit fixes
this by discarding more (although probably the whole header/footer
shouldn't even be parsed to begin with).
The test from b349d2483e actually checked
for this incorrect frame, so change that (the whole test is suspicious, as
the end result is quite far away from what the original doc looks like).
Change-Id: I2e7192e00237db1f030d0524c5667fe92c9e496b
When two pictures apply different effects to the same picture, it is
only saved once in the original document. Added a cache to DrawingML
to know if the picture has already been exported, and added a test
for it.
Change-Id: Ia25f3d8f2f46d61f18aefc22fdfdbcdc72f2d916
When Word applies an artistic effect, it creates two embedded files;
one contains the bitmap with the effect and the other one contains the
original bitmap to be able to undo the effect.
This patch reads the original bitmap, stores it in the shape grab bag
and saves it back to the docx file. Added unit tests too.
TODO: right now, if two effects point to the same original bitmap it
is stored twice, we should improve this.
Change-Id: Ia72034a257739abe4ffafa0f42b2a912e4bf9436
Bitmaps can define artistic effects like in the following example:
<a:blip r:embed="rId5">
<a:extLst>
<a:ext uri="{BEBA8EAE-BF5A-486C-A8C5-ECC9F3942E4B}">
<a14:imgProps
xmlns:a14="http://schemas.microsoft.com/office/drawing/2010/main">
<a14:imgLayer r:embed="rId6">
<a14:imgEffect>
<a14:artisticMarker trans="14000" size="80" />
</a14:imgEffect>
</a14:imgLayer>
</a14:imgProps>
</a:ext>
</a:extLst>
</a:blip>
LO core doesn't support them, but I'm preserving them using the shape
grab bag. Bitmaps must not be transformed to a SwXTextGraphicObject
so the grab bag of the XShape is not discarded.
Added several Context and Properties objects on the import side to
traverse and save the relevant tags, and added the corresponding code
on the export side to extract the grab bag and output the effect back.
Also added a unit test for a selection of artistic effects.
TODO: Word saves the original bitmap as an embedded wdp file so the
effect can be undone. We must preserve it too and add the reference to
the a14:imgLayer tag.
Change-Id: I61d427f83e4c8f353eb073da0114cd73ba50ba4b
Issue :
- Document contains a Section break(Next Page) with a drawing.
- Section break is manullay adjusted before the drawing.
Hence in original document.xml it wsectPr comes as
a part of w:pPr of paragraph.
- But in RT in document.xml, section break is written
by adding a dummy paragraph.
- This is because <w:drawing> also contains a paragraph
and hence when encounters section property LO creates
a dummy paragraph and writes it in between runs.
- This was causing the corruption.
Implementation :
- Added a member varaible m_bDMLAndVMLDrawingOpen.
- It is set to true when it writes drawing.
- It's value is checked in DocxAttributeOutput::EndParagraph()
If m_bDMLAndVMLDrawingOpen is true Do Not make
m_bParagraphOpened to false, as one more paragraph is still
open.
- This will postpone the writing od Section property and will
be written inside w:pPr and no dummy paragraph will get
created.
- Added Export Unit test case.
Change-Id: Ifa26fcaf8f02e62d020339670c8ba58ba92d9f40
Reviewed-on: https://gerrit.libreoffice.org/9430
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
The motivation is that this test takes time to execute (and we're
testing a limit here, so it's not easy to speed it up), though moving it
out of CppunitTest_sw_ooxmlexport is still possible (which is the
current critical path during a toplevel 'make').
Change-Id: Ibe6580f8aea1439f4feb281996f2f4bbd46ff4ce
File is getting crashed while saving in LO, as it tries
to access the value of vector after erasing that value.
Code changed to access the vector value first and
then erase that value from vector.
Change-Id: I29369b7582fdbd7363d0e6fdae091a30c79a747d
Reviewed-on: https://gerrit.libreoffice.org/9433
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Also fixes fdo#42899 and fdo#67685 in a different way; the previous fix
for fdo#42899 caused the problem with password-protected libraries for
which the password is not known: only the binary representation of the
BAISC module was stored, not the source code; by simply copying from the
source storage the problem can be avoided.
It would be possible to ask for the password when storing, but that
would not work when non-interactive (called via API).
An alternative fix would be to pass in the
SfxObjectShell::IsSetModifyEnabled() flag and actually reset the BASIC
library's modify flag correctly, but that requires adding a
parameter to XStorageBasedLibraryContainer::storeLibrariesToStorage().
(regression from af34774d26 )
Change-Id: I4701401f35171139fc2fe8d225d13d4e533091a0
Problem Description:
1. On 19th May windows daily build
[Build ID: dd0f844728, TinderBox: Win-x86@42, Branch:master],
if we RT document, RT get corrupted due to the exceeding the limit of extend height & width.
2. As per ECMA standard, extend height & width is of type long, but MSO only
support int32.Hence added code changes to check the same.
3. On 20th May windows daily build
[Build ID: f3a46244a0, TinderBox: Win-x86@42, Branch:master],
if we RT document, it get corrupted due to exceeding value of posOffset.
4. Added code changes to make sure posOffset value is within the allowed range.
Reviewed on:
https://gerrit.libreoffice.org/9424
Change-Id: Ib0b55314f54c51f39a492485992356f71eb062e3
Originally a Field began inside a hyperlink but ended after the hyperlink.
This causes the corruption in MS Word.
Incremented the field count if the field is added for the current new hyperlink.
Added another variable to store the Field-Count from previous hyperlink.
Added UT for the same.
Change-Id: Id3c3bee1c8ed9c0755f8fff7efd5d1c5662f2c82
Reviewed-on: https://gerrit.libreoffice.org/9421
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
When we have <w:br> tag continuous like in the following cases...
"Title: Superstition\v\vComposer: Stevie Wonder\v\v"
or "\vLyrics: \v"
where "\n" is internally replaced by "\v" LO.
Before text "\v" or after text multiple "\v" is not preserved.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/9420
Change-Id: I2a6d0a7d2382dfbc2f0ab04f150653c9b17bbfd1
In a hyperlink, extra field with fldCharType="end" is getting added
even though there is no begin and separate fldCharType. When hyperlink is
closing pageref was not set to false. Due to which LO was adding extra
end fldCharType.
Change-Id: I0f54ab03c38cec2888cf9a1638ec5435da90099c
Reviewed-on: https://gerrit.libreoffice.org/9414
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
- Normally if there is a case where text/shape is overlapped with (another)
shape then LO used to write the text and the AlternateContent in the same run.
- This is supported in MSO and there is no visual difference.
- But in case if the SdtContent(with text) is overlapped with the Shape then LO
processes sdtContent as a text and ends up putting the alternateContent and the
text in a single run. Ultimately it includes the entire run in a SdtContent,
which is incorrect.
- The fix checks for the aforementioned scenario and puts them in a different run
and also restricts the sdtContent being written in an invalid AlternateContent.
Change-Id: I36f4cdb1b583523dd8f717ae094bdf09c7a61f62
Reviewed-on: https://gerrit.libreoffice.org/9374
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
A file contains a 2007 word art within a drawing tool.
In Original file, the xml structure is as below:
sample xml:
<p> <r> <ac> <drawing> <txbx> <txbxContent> .. <pict> </pict> </txbxContent></txbx> </drawing> </ac> </r> </p>
LO was preserving this as :
<p> <r> <ac> <drawing> <txbx> <txbxContent> .. <drawing> <txbx> <txbxContent> ..
</txbxContent></txbx> </drawing> .. </txbxContent></txbx> </drawing> </ac> </r> </p>
Now after this fix, If there is a custom shape within a text box, then we should postpone it and write it in
a separate run.
This approach is followed on the fact that LO writes nested TextBoxes in separate run.
NOTE1 :Due to this fix, xpath related to the below UT needs to be updated.
testFdo76249 in ooxmlsdrexport.cxx
NOTE2: In docxsdrexport.cxx : 'm_bIsInDMLTextFrame' is no more required.
For adding LockedCanvas, we only need to check if the property exists in the property set.
Therefoew removing the above bool variable.
Reviewed on:
https://gerrit.libreoffice.org/9392
Change-Id: I00e94712e912ad1977fcb65a945fefb927795d77
Description :
Docx file corrupt after roundtrip.
Root cause: For some documents During export LO was not checking for the content of sdt and Even if sdt contains Drawing object
LO was writing text data related tags <w:text/> & <w:dataBinding> in <w:sdtPr>,This was the reason for corruption.
To Fix this checking is there is any Drawing Object in run if yes skip writing <w:dataBinding> tag in <w:sdtPr>
And if sdt content is Text and Drawing both do not write <Text> or <Picture> as these tags will again result in corruption.
Presently, while writing the sdtContent tag LO does not check for the content type due to which LO ends up adding the dataBinding along with the
Drawing/AlternateContent which is incorrect according ecma ECMA-376, Second Edition, Part 1 : 17.5.2.6. This cause in file corruption.
Added a check to restrict the aforementioned.
Reviewed on:
https://gerrit.libreoffice.org/9371
Change-Id: Id31437db0309b0a2159389a4a9a1f5e13c1ac3a5
While export, locked Canvas is missing and drawing is
exported inside textbox. However a locked Canvas has to be exported
inside a text-box and drawing should fall under locked Canvas
for the RT file to work in MS Office 2010.
Reviewed on:
https://gerrit.libreoffice.org/9377
Change-Id: Iea2c411302b552db18527001cc4c6d0290085afe
If docx file contains multiple hyperlinks in one paragraph
and one of the hyperlink contains "PAGEREF" field. End tag
for "PAGEREF" field was not exported hence it was causing
corruption in exported file.
Fixed export part of field end tags in case of "PAGEREF".
Added unit test.
Change-Id: I18a3625213bf7269e3f441859a27acc38cf6ff45
Reviewed-on: https://gerrit.libreoffice.org/9364
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
The original file contains two text boxes one contains image and the other contains chart.
Image in text box is not getting imported in LO which leads to no contents inside the a:graphicData tag which is causing the corruption.
Root cause is found in ShapeContextHandler::getShape.
mxChartShapeContext.is() returns true even when mnStartToken is not set as NMSP_dmlChart which is causing the issue.
I have added one more condition to handle this.
Change-Id: I6c567d7618b34c1a24f6809801e4460af6894c67
Reviewed-on: https://gerrit.libreoffice.org/9363
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
As the m_oldTableReference->m_pOldTablepInner was not cleared
the same tabled was incorrectly nested with itself.
Another issue was that the same table was mirrored in RT file
as LO was trying to export a Section break within a table cell.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewe on:
https://gerrit.libreoffice.org/9361
Change-Id: I09b730a10f1a0bc4434050e0078aeab3185de817
