This does not have an effect on the resulting document yet, but handling
"tight" properly is necessary to support wrap polygons in the future.
Change-Id: Iff057a1f9aff792b9c0ad5e601f2024bc60383cf
Commit 6cac123a8de8357cf11d9b5f818233889d729939 (fdo#45183 import
RTF_SHPFBLWTXT, 2012-12-27) fixed this already once in the past -- fix
it again, this time with a testcase.
Change-Id: I0cbbfb1ba4eef42b2ee32f6f77065afaad3ddc1b
The motivation is that once all the namespace aliases in
writerfilter/source/ooxml/model.xml match the ones in
oox/source/token/namespaces.txt, then the writerfilter copies could be
dropped.
Change-Id: I1f9abb8bb457189997f28c99b0f6b00660252c14
workdir/CustomTarget/writerfilter/source/ooxml/OOXMLFastTokens.hxx was a
duplication of workdir/CustomTarget/oox/generated/oox/token/tokens.hxx,
except when the oox generator changed, the writerfilter copy was not
adjusted and Bad Things happened. We don't need this.
Change-Id: Id92481f110b04ec24cb424421aa0ec029b7896f3
The font definitions in the style sheet meet an untimely death in
StyleSheetTable::lcl_sprm(), which special-cases LN_EG_RPrBase_rFonts,
routing it into TblStylePrHandler.
Avoid this by sending style entries to the domain mapper in the same way
as the OOXML tokenizer, i.e., with paragraph and run properties nested
below CT_Style_pPr/rPr.
This reveals that the CT_Style_basedOn was wrongly handled as paragraph
property.
Change-Id: Ic724ba48fe36bf782b1b430bdafdb1df480d5ad3
The content of \upr and its nested \ud destination should be the same
modulo text encoding, so ignore the legacy one.
Change-Id: I007151e3075a9ac879a486ec3b5fb8549435dbba
Regression from 2a35f5c7945d00b6f6e21fc7cf5b05b184eba88f (DOCX OLE
import: inherit anchor type from replacement graphic, 2014-02-18), then
problem was that dmapper expected that the anchor type of the
replacement graphic is set, but the RTF tokenizer wasn't adapted to
fulfill this requirement.
Change-Id: I0f7e1a71052f337793d6f844fe5476c3868c03f4
The paragraph properties need to be applied to the paragraph following
the \page too, which did not happen in this case.
Also the minimized test doc shows that checkNeedPap() must be preceded
by checkFirstRun(), since there is no run preceding the \page.
(regression from 94765a1b3f543b3b60f8c1de05048d12f2576be4)
Change-Id: Id286c4fbdeee688fa4f6b24063b634bac637eab6
Apparently the StyleType enum is specific to the domain-mapper, the
OOXML filter has integer constants in its model.xml file...
Also surprisingly the section styles only exist in RTF; w_ST_StyleType
in "ECMA-376 3rd Edition" only contains the 4 values of StyleType enum.
Change-Id: I5407800f801824676df309b3705e233cf1382721
Word can apparently have complex footnote separators, but the
domain-mapper only sets a single flag that there is a separator
(m_bHasFtnSep), so the only thing that makes sense for \par here
is to completely ignore it.
(regression from e1afe4318787425dc40f2d0b1f02fa17e925c8da)
Change-Id: I32d9b01a0a9248ba646654295a74953a6cb74fb3
The problem in the bugdoc is that the ';' style terminator is encoded as
{\uc1 \u59 ?}, i.e. inside a group, so when reading the ';' the
aDestinationText of the top group is empty and the style name is lost.
Or since the style name characters are encoded in the same way, every
character is lost once the group closes.
The same problem affects some of the document properties.
Introduce an abstraction of RTFParserState::aDestinationText so that for
every destination only one of these buffers is used, regardless of
nested group structures; the aDestinationText buffer is only switched
when entering a new destination.
Also, the \revtbl and \stylesheet destinations do not contain entries
directly, i.e., every entry must be in a sub-group, so remove some
special-casing for these; however, for \fonttbl the entries may be in
groups or not.
Change-Id: Ica276a8b730e4a707530471ba27bfdd1582b8890
The ";" terminates an entry and shall not be inserted as text,
even if some over-engineered producer encodes it as {\uc1 \u59 ?}.
Also, remove the special-casing of the \leveltext destination, since the
bugdoc does contain \uc inside it and it's not obvious why that should
be ignored.
Change-Id: I1e19c9df39597cb1b22bbda97853c829d7812e29
With a horizontal rule, it's possible that there is no \par following it
in a header, so RemoveLastParagraph() will delete the paragraph where
the shape is anchored (and so the shape as well). Avoid that by adding
an extra \par if there is no \par following a shape.
Change-Id: I4840417880c98203866c9dcde51627516618f2d0
There are special properties to create a "horizontal rule" shape
that apparently set some specific defaults; this prevents the
shape being imported as a big fat rectangle over the document.
Change-Id: I402376d7306e870ad895beaa657750cbf3290d98
The document has a \pict with {\sp{\sn shapeType}{\sv 1}}, i.e. it's
actually a rectangle shape; Word seems to ignore the picture data in
this case, so try to do the same. Also consolidate the shape creation
in a new function RTFSdrImport::initShape().
(regression from ba9b63d8101197d3fd8612193b1ca188271dfc1a)
Change-Id: Iec94852ddc4c1ca3d8284119e6f1818a8dbb4149
For shapeType PictureFrame, a default CustomShape was created and then
RTFDocumentImpl::resolvePict() crashes because it actually operates on a
previous shape, because in this special case RTFSdrImport::m_xShape
is never actually set to the new shape, so contains the previous one.
Also the new shape needs to be added to the draw-page, at least
otherwise the assertion of the supported service fails because
some SvxShape::mpObj weak-reference is dead?
This essentially reverts commit 3cab1adf19d553663685e8198f0ec3f258a37c36
(except for the added testcase, which was slightly different because
it did not have a "pib" property).
(regression from ba9b63d8101197d3fd8612193b1ca188271dfc1a)
Change-Id: I6539c4286850dff2d8564006487cc765f1d117be
