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
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
This is a variable-length encoding, and the second byte may be a RTF
syntax character like \, {, }.
Change-Id: I813ccafda18388af3bf05eb7ce9a0253c627b1c4
In the past, LO did not support 'outset' and 'inset' border types
for tables, so when encountering them - LO converted them to other
types of border. Now that LO supports it - DOCX and RTF filters
were changed to import these border types correctly.
DOC filter was not changed, because creating a proper DOC sample
file that has these border types (needed for the 'bordertest.hxx'
file) was not possible right now. So at least DOCX and RTF filters
are fixed.
Change-Id: Ida2449d45a0ac138388f3cbfeb41657db1d4cda9
Signed-off-by: Michael Stahl <mstahl@redhat.com>
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
Regression from a48e2fd9049797110b3b2505c363557284987ca8 (fdo#44736 -
convert RTFSprms to a copy-on-write structure., 2012-12-07)
Change-Id: I2538f440e29cef6d40db2ea914e4afcbfe411890
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
This scenario is not a valid one, Word doesn't handle it, either -- but
the old LO 3.4 parser did. So add minimal support for it to avoid
the regression.
Change-Id: Icc2e8d3bf314e9cadda57956668033aa6d092457
Commit bbe3627eece0c3486e7ea11f2f13377aaa3a8fed (rtftok: stop sending
sprm:CRgFtc{0,1,2} tokens, 2014-03-05) dropped support for case when a
font name is used in multiple entries in the font table, but with
different encodings.
Turns out that this is a valid use-case, so revert back to the old
behavior where the key of the encoding table is the font index, not the
font name.
Change-Id: I048dff58af801d704fd4bc75a6a4dcb0f03bf185
Commit 1eaab77c718ffa254068ae6032862dfb5a03db67 (fdo#60722 import
RTF_SHPZ, 2013-03-06) changed how we handle z-order, in case two shapes
have the same value. Turns out for drawing-objects the order is the
opposite in this situation.
So fix this by adding a new mode, that keeps the original testcase happy
without breaking older documents.
Change-Id: Ib2d284cefc3c0dce40ac2e516ba260d6cd04ce43
The problem was that dobxpage arrived first, set HoriOrientRelation to
FRAME, then dptxbx tried to apply defaults, which overwrote the already
set HoriOrientRelation. Fix this by only applying properties which are
not set yet.
Change-Id: I108f3363a2758eee0242533fe92e511e8c522b68
The previous fix for this bug only fixed a symptom, this a fix for the
real problem; with the real problem fixed the nCellEnds is unnecessary.
Given that top-level table properties may be put either before or after the
table cells, the only way that works to import tables is to buffer a whole
top-level table row, but currently the buffer is replayed already at the
end of a nested table row.
Fortunately the RTF spec guarantees that \nesttableprops must occur
after the nested table cells of the nested row, so it should be
sufficient to remember the cell properties for the current nested table
row only, in addition to the cell properties for the top-level table row.
With this change, skipping a \nesttableprops destination when there is
a table style turns out to mangle ooo98040-1.rtf badly, so stop doing
that workaround.
RTFDocumentImpl::popState() was copying various buffers up the state
stack which is a clear indication that these shouldn't be members of
RTFParserState in the first place, move them to RTFDocumentImpl.
Change-Id: Ic2d8f7b3e00844b224d61605b405ca651239e5f7
In this document written by "XMLmind XSL-FO Converter" there are less
\cellx than \cell and thus when reading \nestrow/\row a whole buffered
nested table \cell is lost and then subsequently the rest of the nested
table too. Try to fix that by counting both \cell and \cellx and
replaying until the maximum of those.
Cannot count \intbl since we synthesize that in various places.
(regression in LO 3.5)
Change-Id: I3b64ad94af842e076611418589a0c83bd18841c6
Commit 330b860205c7ba69dd6603f65324d0f89ad9cd5f (fdo#68787 DOCX import:
handle when w:separator is missing for footnotes, 2013-09-04) disabled
footnote separator by default in dmapper, as the OOXML tokenizer always
provided a uFtnEdnSep in case a separator was wanted.
Let the RTF tokenizer do the same, this way we're in sync with Word
again: if RTF_CHFTNSEP is in RTF_FTNSEP, then we show the separator,
otherwise we don't.
Change-Id: I74b46c5d71227682e093695336dc9eb6fde22121
And not the other way around, how
24ee3df385cf2aa95cd888581c84fdf90cc682dc (RTF import: fix priority
handling of shpz vs dhgt, 2012-04-10) did, this time with a reproducer.
Change-Id: I9412341c6b35ca2760e4490a18f11bc6a0e0b78a
These describe an explicit horizontal merge, that is not something Word
itself creates, but it turns out the Calc RTF export does.
Change-Id: I1b6ec10bb8e8bd40e24791ccc96f2f066dd0d5d5
Updated 3 testcases, in all cases first checked that the new behavior
matches what Word does.
Also added a new test, to check that empty para at footnote end is now
kept.
Change-Id: I96b8788feb4d730b5a64ba3a743311a0180ab41f
Pictures typically have a single RTF group, so we imported them at the
end of that group. Though multiple inner groups are also allowed, so
make sure we only do the import at the very end, instead of at the end
of all inner groups as well, resulting in multiple (fake) pictures.
Regression from 13c00ce322e78eb4e0f50ab84ded19cd6aae1ded (Enable the
writerfilter-based RTF import in non-experimental mode, 2011-08-18).
Change-Id: Id895b2c6d3b824d09d89bfa01ce59aba76c55d42
Regression from 2ade07126971b79c92f729fae5709f2e2e2b495c (fdo#62044 RTF
import: don't overwrite existing styles when pasting, 2013-06-04),
during paste, if existing style was found, then the intention was to
skip that style, but instead we tried to create one.
Change-Id: I83adaf9fe6b8a578fa60c21b9463fabde7707d7e
In general, paste should not deal with page styles. In this case, it
even caused an additional page break.
Change-Id: Ia7c5a9ad844821b6622babfbd94469ec3c04cf0a
Commit 4a507f732d82c188ad81b022cbe3037951e58ac3 added an exception to
RTF_PARD (reset paragraph properties) handling: when we're inside a
table, it should not reset the fact that we're inside a table (which is
a paragraph property).
However, instead of just re-adding that property, it disabled resetting
for all properties, and we had a growing list of exceptions since then.
The next thing to add there would be the paragraph attributes, which
contains the style information. Instead of growing that ad-hoc list,
reset everything again and just re-add the "in table" SPRM.
This makes the second and later paragraphs in the A1 cell of the bugdoc
have proper font size.
Change-Id: I2de80894fcd5da3bf45d221af9a04a307c70a29b
There were multiple problems here:
- xFoo->createTextCursorByRange() got a text range argument,
where the text range wasn't from the xFoo text
- it was assumed that all XText implements text::XParagraphCursor as
well, but this is not true for e.g. comment text
- commented text ranges were pasted as normal comments (once again, the
insert position wasn't passed around)
Change-Id: I9a975a08b08a7f32b1ee71e42f58736cc0dbb09d
The document had 3 sections, separated by continuous section breaks.
Previously only margins from the last section were imported, this way
the first page had default margins.
Now margins are also applied when we hit continuous section breaks. This
way margin values from the last section break affecting the page wins. A
later commit could improve this further by setting the minimum of these
and setting a section margin for each non-minimal sections.
Change-Id: I4d9a4585e795220533909bd1d467d933caaa0d71
This is the RTF equivalent of f5b7acac624f07fa95835b6054b8d295901bb1dd,
which avoided TO_PAGE-anchored shapes in the VML importer.
Change-Id: I58a5cdb311ac43ddba00bc441005fb37a4899cee
Instead of unconditionally calling addProperty(), first check the
existence with hasPropertyByName() and call setPropertyValue() instead,
if necessary.
Change-Id: Ie0a075bbfe6eaa1f66726c456105dcdef9001d30
Both Word and Writer typically write all paragraph properties before the
first text in each paragraph, but at least for paragraph alignment, it's
valid to write them at the end.
Change-Id: I0337e63678ad45c662a204ab2fc59378607abe74
This crashed because for a single listoverride entry 2 SPRMs were sent
to the domain-mapper, and the second one was empty.
Change-Id: Ic41ffd8bd4edcff065f49ecef3464efedd909d63
In case we have a table of a given width and the second (or later) row
has fewer cells, we have to add a fake cell to such a row. However, it
doesn't make sense to do this when the difference is only a few twips:
we can't create such a small frame inside the cell later anyway.
Regression from c3b0f13546b30e5db3aecd311c7178e4e0933208.
Change-Id: Ibc0f02d4184b58bd423c3405e786e1ec25b9dd13
