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
b88fe998ce 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 07d01742c6.
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
Like the minimal filter tests, these tests are invoked from a single
cppunit method since commit 0a30cb22a1, so
some info about exactly what file failed is necessary. If we are at it,
also print the (re)loading time as well.
Regression from d4069372484f18b242a42a1996767f57b031fff6
Change-Id: I28e095819e0c2f1a4b110741ace366329937f863
Reported-by: Michael Stahl <mstahl@redhat.com>
