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
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: Ie656f9d653fc716f72ac175925272696d509038f
The BRC (BoRder Control) structure used in .doc files to specify border
properties has undergone several revisions over time. LibreOffice
supports the WW6 and WW8 (Word '97) BRC versions, which allow the border
colour to be selected from a palette of only 16 colours.
This changeset adds support for the WW9 (Word 2000) BRC version, along
with some new SPRMs (Single PRoperty Modifiers) which use it, so that
border colours are preserved accurately in .doc import/export.
This change covers:
- page borders
- paragraph borders
- borders around a sequence of characters
- table / table cell borders (import only)
Further work is required to extend coverage to borders of pictures and
export of borders in tables.
The LO code was using the same class WW8_BRC to store the bits for either
the WW6 or WW8 BRC. This becomes a bit unmanagable when adding a third
BRC version, so I have split this into a separate class for each version.
Fixes fdo#68475, fdo#50185
Change-Id: I7ebc15236497cbab9312d8659fe7ed0bee2c59ed
Reviewed-on: https://gerrit.libreoffice.org/8646
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This was generated previously in writerfilter, but keeping around an XML
file of 8000+ lines just to generate these constants is an overkill.
Additionally, these constants are hardwired in all available WW8 files,
so they won't change. By copying it here, it's possible to incrementally
remove what's still remaining from writerfilter's not used doctok.
Change-Id: I1d30da1f635946b15a37de68080fd9eebc2ad88e
Cause:
- In altenrate content, Fallback contains only group tag.
Implementation:
- Added export logic in Vml export.
- Added unit test case for vml group.
Change-Id: Ia1c9834950528dc892caea1cb675a7f42165d9ba
Reviewed-on: https://gerrit.libreoffice.org/7276
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
Grab-bagged the "editas" attribute of v:group and added UT for
the same
Please verify this fix on MS Office 2007 as it renders the mc:Fallback VML part
Conflicts:
sw/qa/extras/ooxmlexport/ooxmlexport.cxx
Reviewed on:
https://gerrit.libreoffice.org/7335
Change-Id: I4e4456997621089967514009005ee775b71d6d69
