ie.
void f(void);
becomes
void f();
I used the following command to make the changes:
git grep -lP '\(\s*void\s*\)' -- *.cxx \
| xargs perl -pi -w -e 's/(\w+)\s*\(\s*void\s*\)/$1\(\)/g;'
and ran it for both .cxx and .hxx files.
Change-Id: I314a1b56e9c14d10726e32841736b0ad5eef8ddd
This option allows images and drawings to be skipped while importing
DOC and DOCX, for text-only conversion or indexing.
Change-Id: Id4bfbbe48d8a8e970b1cb5922187768bf94dc918
Reviewed-on: https://gerrit.libreoffice.org/14733
Reviewed-by: Németh László <nemeth@numbertext.org>
Tested-by: Németh László <nemeth@numbertext.org>
DOC export has a good approximating algorithm for that
so use it everywhere.
In RTF case use the default color table which is added
also by MSO Word. With that highlight colors are also added to
the table.
Change-Id: Ie4827a933c316d4dc0c0c7a32d8cf319477d1bf9
Where we can prove that the virtual method is never overriden.
In the case of pure-virtual methods, we remove the method entirely.
Sometimes this leads to entire methods and fields being
eliminated.
Change-Id: I138ef81c95f115dbd8c023a83cfc7e9d5d6d14ae
from PptSlidePersistList.
This also puts in assertions that every entry in a PptSlidePersistList
is non-null.
Cf. 9536a28ede89e8c29940e8ba225215a45667062c
Change-Id: Iea35532ed668e58a3f02d3f3433a66c2d4e1fe2a
Reviewed-on: https://gerrit.libreoffice.org/11807
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Put the TOOLS PolyPolygon class in the tools namespace. Avoids clash with the Windows
PolyPolygon typedef.
Change-Id: I811ecbb3d55ba4ce66e4555a8586f60fcd57fb66
Problem Description:
The docx file contains a word art inside a drawing tool.
After RT, nesting of <txbxContent> tag is happening which
is causing the corruption.
Solution: Created a service in util.cxx for checking
few shapetypes for which textbox with content is not
allowed. This check also helps to find that if we are
already inside a DML then we should purely read VML
Information.An existing UT testWordArtWithinDraingtool
was failing. The UT is related to same issue
(word art inside drawing tool) hence changed it
accordingly. Following is the commit id of the
UT-Change-Id: I00e94712e912ad1977fcb65a945fefb927795d77
Change-Id: I7e456c9f6a69af80da443e29eb02a64ba7d59468
Reviewed-on: https://gerrit.libreoffice.org/10229
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Luboš Luňák <l.lunak@collabora.com>
I understand that Libreoffice's names for SPRM IDs come from old
documentation for WW8 (Word '97), plus some later additions named by
OpenOffice developers as they encountered newer SPRMs in the wild.
Meanwhile Microsoft has released newer documentation which supplies
names for these previously undocumented SPRMs, plus it renames some
WW8 properties to have the suffix "80" to make room for newer
versions of those properties.
This commit aims to bring LibreOffice's SPRM ID names in line with
the current file format specification from Microsoft.
http://msdn.microsoft.com/en-us/library/dd923581.aspx
Change-Id: I904c1db17a776e2d9e6076f87369160e3b80f2e4
Reviewed-on: https://gerrit.libreoffice.org/8884
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Currently LO writes table cell border information to .doc files as part
of the "sprmTDefTable" property, but this only supports the WW8 (Word '97)
BRC (BoRder Control) structure which can only select from 16 colours.
There is no newer version of this property.
This commit adds output of an alternate property "sprmTSetBrc" which
specifies border details for a sequence of cells. There is a WW9
(Word 2000) version of this property supporting full colours.
For LO I have used the constant name NS_sprm::LN_TSetBorder following
the existing naming convention here, which is to use *Border for the WW9
version because *Brc is taken for the WW8 version.
Conflicts:
include/filter/msfilter/sprmids.hxx
Change-Id: Ie091d91c6d187e1c2542f59f58cec9a373a23e11
It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
