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
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
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
In case the URL text has multiple portions, then MSWordExportBase
generates multiple URL's anyway, and this helps to avoid loosing some
direct formatting of the remaining portions of the paragraph.
Change-Id: Ifd72741de610ce69b9ae0978aa8f9a532a3aeed2
Fill attributes with their original WhichId are only used for frames at
the moment, replacing RES_BACKGROUND. To keep export filters working,
handle those fill attributes as frame ones as well.
Change-Id: I1e59b483b706d9fd3f9b947e83244740e3293f9e
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
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
This should be in sync with model.xml, got broken when the somewhat
random values got fixed to be the same as the ones which are in the ww8
spec.
(Regression from 26d40686128e70916a636e20f5ccc5763bbb6cc8.)
Change-Id: Id62047e0b2d5d8402a7c8bce95de487afe627e32
Change the order of words BORDER and EQUAL in the
macro name to become consistent with other macro names.
e.g. CPPUNIT_ASSERT_DOUBLES_EQUAL
Use a function inside the macro to make it type safe.
Add additional message to make clear why the test failed.
Change-Id: I9fc7a5813adf2cac36ae831d438cec498232b06c
Reviewed-on: https://gerrit.libreoffice.org/5885
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
-Use sprm:CBrc attribute for all MS filter (for ooxml too).
-Extract general code to FormatCharBorder() method, it selects
the border side and decides whether add shadow to the border.
-RTF export has a color table, which must be filled with border
colors before the actual export.temp
Change-Id: Ic3ceae6e19ddc2ed5aaa8de85617f9a592289b4f
MSVC misinterprets UTF-8 source code without BOM as ANSI/OEM codepage.
For that reason if local codepage is unfriendly to UTF-8, it sometimes
causes compilation error.
Change-Id: I8acd5500e581e020fd60b5a2ec20629f92fdf87c
Even if level text is not ASCII, we should just write the placeholder
values (0x00, 0x01, etc.) in a hex encoded form, without Unicode.
Regression from 07d01742c69f1c0335bc7e1b57abd8341ce255e7.
Also, fix the import side, so the previous bad output now looks bad in
Writer as well.
Change-Id: I2f93892006c07eec243ec7dfcb23372d243a2db4
There were two issues here:
1) The export filter never exported these keywords.
2) The "flymaincnt" RTF extension we inherited from OOo actually never
worked (i.e. it's like this since 7b0b5cdf, the initial import...), as
RTFVertOrient / RTFHoriOrient's second parameter was stored in 1 bit, so
text::RelOrientation::PAGE_FRAME (7) was read back as 1 instead.
Note that I want to get rid of this flymaincnt extension in the exporter
anyway soon, so killing the RTFVertOrient / RTFHoriOrient duplication is
pointless: the sw version will go away.
Change-Id: I5335567833ecf87e6b0ba7c73150a7b95c57f237
