DOCX export tries to write accurately both <w:br> and
<w:pageBreakBefore>, while DOC/RTF prefers just the page break before
paragraph attribute. Given that these later two exporters are not
adapted to write their equivalent of <w:br> at all, add a virtual method
to determine if writing page breaks as "page break before" is preferred
or not, that'll give the expected RTF export result.
This conditionally reverts commit
a31fbb53dba76736b37213b98b64937f05929a67 (fdo#74566:DOCX: Preservation
<w:br> tag for Break to Next Page, 2014-02-06).
Change-Id: I4a5dd295b07739a570cd8cc6709561e64d031273
Without this, in case TextAutoGrowHeight is set before TextBox, the
textbox of the shape won't have automatic height.
Change-Id: I2ebf77eacbe1f1d10ccf64ef833c39ee965245d3
Ensure that we export only one \fldresult per hyperlink by doing that in
StartURL() and EndURL(); the TextINetFormat() is called once per text
portion. This shouldn't cause problems as there can't be anything
between the end of the \field group and the start of \fldresult anyway.
Replace the annoying call to EndURL() from EndRun() with a special case
in EndURL() to store things in the right buffer (hopefully).
(somehow this is regression from c4498251cb7181a9f272b0720f398597c0daef09)
Change-Id: I209ea7a384fb1cb5d1505a70ecc4a4536bbf26a2
Bugdoc has 2514600 EMU's as the vertical position, use that, and allow
larger values, as originally this was 0, and we have additional 2 mm100,
probably due to rounding errors.
Change-Id: I7495a0f9e913332a24d0a830b0252ecb6a39d806
When we have multiple tables inside a table, the tblBorders and
tcBorders of the inside tables are not getting preserved.
The issue is m_aTableStyleConf is not clear when the LO starts
writing the properties of the inside table.
Change-Id: I30081b8a5a59614430a2279550ae7eb589cb71ec
Reviewed-on: https://gerrit.libreoffice.org/9893
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It builds a textbox -> shape map, so methods interested to pick the
shape instead of a shape's textbox can call it and act accordingly if
their textbox is in the map.
Change-Id: I0f30d64a284eb461f462ed6c0a36c88271153f04
Changing a document with redlines to two columns and then using undo
set some redlines to point to the end of the document (done by
the call to RemoveIdxFromSection() in SwUndoInsSection::UndoImpl()).
Change-Id: I88b563b88beebcd1c3cb21fe61bb56cdb12cdc41
The reason the section ended up with incorrect margins was because
that is computed as 'page margin' - 'section offset', and the order
of setting these up was backwards: First InsertSection() created
the section using the page margin of the old page, and only afterwards
SetSwFmtPageDesc() set the page margin that should be used.
Change-Id: I18ddcb0b5928879a2297b6caca766eab979abd45
Find places where we are returning a pointer to something, where we can
be returning a reference.
e.g.
class A {
struct X x;
public X* getX() { return &x; }
}
which can be:
public X& getX() { return x; }
Change-Id: I796fd23fd36a18aedf6e36bc28f8fab4f518c6c7
If we delete a shape that had a textbox, then delete that textbox as
well. Without that, the doc model would be still consistent, but most
probably would not be what the user expects.
Change-Id: Id5075233ce66d7a398c88ff3e63b05a6b2133571
The document contained a few unrelated shapes and it was reported that
those cause testcase failures, depending on the version of some system
libraries (at least Ubuntu 14.04 is reported to be affected).
Change-Id: I1aaf02441e2bc30d1a5465b038211deb240a5b69
- In case of framePr attributes being omitted in original xml, LO defaults
such attributes to incorrect values.
- Correcting these values in this fix.
- This fix stops LO from getting hang while saving the document, the actual
fix needs to be somewhere in the table layout. We need to restrict the
frame from being considered as part of the table as MSO does not allow
frame to be part of a table.
Change-Id: I4c35f7eff6ca1122901f5667fc26b849df527f60
Reviewed-on: https://gerrit.libreoffice.org/9774
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Problem Description:
fdo#79968:
1. Document contains embedded powerpoint in docx.
2. After RT, embedded powerpoint object is not preserved.
3. In this case, .sldx is get converted to .bin due to this powerpoint slides
is getting converted to picture.
fdo#79969:
1. Document contains embedded excel work sheet.
2. After RT, embedded excel sheet is not preserved.
3. In this case, .xlsm is get converted to .xls.
4. Similar case happened with binary excel work sheet.
Implementation:
Added sMediaType, sRelationType & sFileExtension for embedded excel sheet,
binary excel sheet & powerpoint slide.
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/9765
Change-Id: I8f94e3f9293f2ac98b61f919d60ca556695b26c2
Values set for docPr name and shape ID attributes in RT file were not valid
as per UTF-8 encoding format and hence was showing RT document as corrupt with
error message "invalid character".
Calling add() function with current parameters is causing issue and
setting invalid values so modified the second parameter which will
set valid values to the specified parameters.
Reviewed on:
https://gerrit.libreoffice.org/9746
Change-Id: I3b48e53adbe5ed844235e596bb98eb396133845a
Issue:
- File contains paragraph with framePr have graphic object in it.
- So Libreoffice converts framePr into textbox.
- So after saving file textbox gets exported with drawing object.
- MS office does not allowed drawing object inside tetxbox.
Change-Id: I673e0e9f6681a189bde1c63a8cb7aea2cac0ab41
Fix: - Export framePr into paragraph and igonre exporting of
dummy textbox added by LO for framePr.
Reviewed-on: https://gerrit.libreoffice.org/9389
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
This allows having real shapes (like having rounded corners) and complex
content (like containing a table) at the same time.
WPS shapes are wrappers around drawingML markup in DOCX files, so this
only affects the DOCX import.
Change-Id: Iad1c1c61233be1c17efa1821e680927aa9587215
Ideally now all testcases handle both cases during DOCX import:
- current situation, when shape with text is imported as a Writer
TextFrame
- future situation, when shape with text will be imported as shape with
an assicated TextBox
Change-Id: I5b95ff4672cecf39eb744f8557f967ade73404c0
In general Writer supports having objects inside a TextFrame, Word does
not. It turns out that Word allows having certain shapes inside other
shapes, as long as they are VML-only. So do that for now: if we receive
a shape when we're already inside a shape, then just export it as VML,
not the usual drawingml+VML pair.
Also, blacklist one more VML shape type, where the shape text is already
exported inside <v:textpath>, so no dedicated <v:textbox> is needed.
Change-Id: I5786bd6827eae9756e7c179bb2ef5a5741a91878
It would certainly be immediately obvious to any reader of the RTF spec
that \sN will apply the style with index N to the current paragraph.
But actually, that is not what Word does when it reads \sN...
what it really does is to apply the style with index N, and then for
every attribute in that style, apply the same attribute with a default
value to the paragraph, effectively overriding what's in the style.
If that doesn't make any sense to you, well, have you heard the joke
about how many Microsoft engineers it takes to change a light bulb?
Also, \pard apparently implies \s0.
To implement that, change RTFSprms::deduplicate() to recursively
look for style SPRMs that are missing in the properties, and put
in default ones, currently just for 2 keywords \sa and \sb.
This requires changing deduplicate() to be const and return a new value,
since it is no longer idempotent, as the erased SPRMs would get
defaulted on the next run.
While at it, fix RTFValue::equals() which did not compare m_sValue.
This fixes the testParaBottomMargin test that was broken by the fix
for fdo#70578.
Change-Id: I4ced38628d76f6c41b488d608a804883493ff00b
quoth the spec:
"For <style>, both <styledef> and <stylename> are optional; the default
is paragraph style 0."
Of course in order to do that we need to add support for at least
recognizing the \dsN and \tsN keywords to override the default, so that
table styles don't become paragraph styles.
Change-Id: Ic100768581f9e8c327063ff776fbd61ac4242483
We used to write out a custom dash definition all the time, even in case
it was imported from a dash preset. Recognize at least "dash", and write
that on export if the parameters match.
Change-Id: Ifaaec51be9ecf1e7667a8c8f85fbd4fb9636a325
In the OutputTextNode, the text data is postponed when the in case of
NOT_PROCESSED state of fly frame. This text data is never been processed
later.
When the text data is postponed we should write this before processing
the next text node.
Change-Id: Ib8d5fdcf8dcfb9ff394d32103502150e08bbd521
Reviewed-on: https://gerrit.libreoffice.org/9737
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
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
