RTFSdrImport::resolve() is called for \picprop and creates an XShape
that is stored in RTFSdrImport::m_xShape and also
DomainMapper_Impl::m_aPendingShapes;
later RTFDocumentImpl::resolvePict() completely ignores that XShape
and creates a new one, which is also inserted in the document;
the first XShape is effectively leaked.
Try to avoid that by re-using the exising m_xShape in resolvePict().
Not sure if there are any problems with doing this, it's all a bit
confusing.
Change-Id: I98456242acb0766f547eb8f7d877f51d53323f3a
If the shape properties are inside \picprop destination, don't set
shapeType.
(regression from 9f1f7199736e2ae07b34849ba66f61a1ef5782e8)
Actually this does not fix the root cause, this is just a work-around,
the extra shape is still inserted but it's invisible now.
Change-Id: I6cf093de2a5657533f393863ed8010ae083bec16
Currently font names like "微软雅黑" (Microsoft YaHei) are
written as "????" in the RTF export; to avoid that, set the \fcharset
of the font entry to something that at least is able to encode
the font name and alternate name.
This requires a new function since the existing
rtl_TextEncodingToWinCharset was changed in
b88fe998ce8c80d7629fe70118311096615d959d to return "default" 0x01
(for OOXML) which is quite unhelpful for RTF.
This is not entirely satisfactory, as of course that is no guarantee
that the encoding can represent all of the actual text that has the
font applied; hence there are some \'3f in the fall-back encoded text
of the heading of the bugdoc, which indicates that the detected
Shift-JIS is insufficient and GB-2132 would be required; but it's not
obvious how to do better here without iterating over all the text
twice, and that still leaves the possibility that all text that has a
particular font applied cannot be represented by a single non-Unicode
encoding.
But since we always write text as the \u Unicode + legacy fall-back,
this should not be a big problem since modern RTF readers will simply
read the Unicode.
Change-Id: Ie6a42294c501d014dd9f0df82638519412ca19bb
Regression from commit abe1e852a232e3bdab7b9177d099fe3929f5a4aa (handle
properly page breaks even if a page contains only a frame (fdo#55381),
2014-04-21), DomainMapper::lcl_endSectionGroup() inserted an empty
paragraph before and after the real footnote text. Disable addition of
the dummy paragraph for footnotes.
Change-Id: I6e1954c9bd5520ac284d66244ce1c9004e970305
Problem Description : For some documents containing redLine data there was already processing done for paragraph properties pPr
but when it comes to DocxAttributeOutput::EndParagraphProperties() instead of writing these pPr, LO was calling Redline( pRedlineData )
which has it's pPr inside w:pPrChange.
This was the reason when LO calls WriteCollectedParagraphProperties() after calling Redline() it was writing both paragraph properties
inside single w:shd element.Hence the RT document was getting Corrupt.
Added condition in DocxAttributeOutput::EndParagraphProperties() which is checking for RedlineData and if it's there call
WriteCollectedParagraphProperties() before calling Redline().
Added Export Test case.
Change-Id: I7000c27fe6ee372cac81d6f22e0d3ca9219a24d7
Reviewed-on: https://gerrit.libreoffice.org/9712
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
- File attached to issue contains footnote between a table and reference
of footnote is in field.
- In PopFieldContext code was throwing exception due to null value of
footnotestartnode.
Reviewed on:
https://gerrit.libreoffice.org/9697
Change-Id: I467e234a7daa6a5f724087c2cc959e4c9d76f4d2
File contains SDT content, in which after export databinding have duplicate attribute.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/9693
Change-Id: Ibe828964c054bdd5a63b5c0c903bc7441d953d72
Issue :
- In file there is a WordArt inside Table.
- In RT, LO exports <w:drawing> inside <w:drawing>.
- The xml sequence was :
<mc:AltrnateContent>
<mc:Choice>
<w:drawing> // first start of drawing
<w:txbxContent>
<w:tbl>
<w:drawing> // second start of drawing. MSO does not allow.
Implementation :
- In DocxAttributeOutput::OutputFlyFrame_Impl() under "case sw::Frame::eDrawing",
if drawing is already open then Postpone the Inner Drawing.
- Added Export Unit Test case to check two separate drawings are
now written in document.xml of RT.
Change-Id: I01d06621576d60d26cd51489ee9718dd79eb9c72
Reviewed-on: https://gerrit.libreoffice.org/9653
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
The import mechanism of custom-dash (a:custDash) was wrong, and imported
wrong values, which causes that if you would import-export-import-export -
you would get inflated values, which might cause a corruption.
The attributes for custom-dash nodes (a:ds) are of type 'PositivePercentage'.
Office will read percentages formatted with a trailing percent sign or
formatted as 1000th of a percent without a trailing percent sign, but only
write percentages as 1000th's of a percent without a trailing percent sign.
During import - LO did not check if it was in '%' format or in
'1000th of a percent' format. So that was fixed. Also - when exporting -
it always exports now in '1000th of a percent' format.
Change-Id: I6bd74df26951974f85173227c832386c70034afb
Reviewed-on: https://gerrit.libreoffice.org/9681
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's possible to write this tag in oox (so it represents the properties
of the shape) or in sw (so it represents the properties of the shape's
textbox). Do the previous, as the textbox is really just a container in
this use case, nothing more.
If we are at it, also fix the default value of <wps:bodyPr>'s l/r/t/bIns
attributes.
Change-Id: I0571b9d8ea7dc0acd5c61f3e28e18400d305eab3
Decription :
- Docx file contain smartart and it was created in MS word 2007.
- MS word 2007 does not create any drawing.xml for smartart
- So in DocxSdrExport::writeDiagram() diagramDrawing was not set in this case.
- File crashing at diagramDrawing[0] >>= drawingDom as diagramDrawing is empty.
Change-Id: I6bc38e702f731ad8074b562572fd50f2e29a41b7
Reviewed-on: https://gerrit.libreoffice.org/9706
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
http://opengrok.libreoffice.org/xref/core/sw/source/core/unocore/unosett.cxx#1884
Modifies the refernced style of the numbering rule to use the current numbering rule.
Actually the refernced style is not supposed to be modified.
As the numbering level formatonly uses that properties particular style,
which may or may not be a numbering style
For this Particular document the numbering format refers the "Default Style" (Normal).
Almost all of the styles in style.xml are based on it. Normal was modified,
and as a result the whole document was bulletized; Which caused the hang while opening
Removed the addition of style as a PARA_STYLE, as the properties of the
refernced style are already added in ListLevel::AddParaProperties
Conflicts:
sw/qa/extras/ooxmlimport/ooxmlimport.cxx
Reviewed on:
https://gerrit.libreoffice.org/9668
Change-Id: I8cc143805a38613908d2e2cb4827882d4cf40a78
This allows us to pass through less parameters which are only used for
this functionality.
Conflicts:
sw/inc/ToxTextGenerator.hxx
sw/source/core/tox/ToxTextGenerator.cxx
Change-Id: I5a03cf8ec6d86d05f2a7f7771668585669c1e595
Reviewed-on: https://gerrit.libreoffice.org/9613
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
When a w:shd has some pattern with two colors, LO blends both to
render the paragraph background. We must compare that blended color
with the paragraph color on export to know if the user has edited it
or not. We were using the w:fill attribute to compare, but that was
incorrect.
Modified an existing unit test to check this behaviour. The unit test
had to be retouched because Word remove some redundant information
from the original .docx file when I saved it again with some
background changes.
Change-Id: Ia2f1ddc4afd2637e1d87b6eccd441c26853045c4
Description:
In RT file the dash length (d) is going out of range,
as after RT the dashing scheme changes to custom dash
which was causing the corruption. Changed code at export,
which will divide the DashLen, DotLen and Distance by
base line width.
Reviewed on:
https://gerrit.libreoffice.org/9559
Change-Id: I0e644b5a2b692a9e717026a14d1f0058199f53b1
The logic was moved to a separate class and unittested.
Conflicts:
sw/inc/ToxTextGenerator.hxx
Change-Id: I0e4475f5e2950cdfdfb07b89128c4ce1d6af3f22
Reviewed-on: https://gerrit.libreoffice.org/9609
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
The separate class allows to unittest this functionality in isoloation.
Change-Id: I1e5eddfb455ca85a662ea38c03302883decc5d58
Reviewed-on: https://gerrit.libreoffice.org/9608
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
These are the remaining changes: with these, if we import "drawingML
shape with text in DOCX" as "shape with textbox", no testcase in this
suite fails.
Change-Id: Ic39cc204e3cfb662f14db1810f7138df0829eb27
getShape() doesn't case if the object is on a drawinglayer one or a
Writer TextFrame, and that's exactly what we want. (Currently is a
TextFrame, but will be a drawinglayer object when shape with text will
be imported as shape with textbox.)
Change-Id: I6ae981700d214447f326e6a0fb550b98380bc10c
Problem Description : While setting ExtraData for Redline LO calls SwRangeRedline::SetExtraData() with
argument of type SwRedlineExtraData_FormattingChanges* which contains SfxItemSet*
In function SwRedlineExtraData_FormattingChanges() without Null checking SfxItemSet*,
LO was trying to get rCpy.pSet->Count() which was the reason for segmentation fault
while opening some documents in LO.
Added Null check before accessing a pointer.
Change-Id: I33299d2be2777ab6a8af0621595c9453145f1069
Reviewed-on: https://gerrit.libreoffice.org/9647
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
