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
The problem was that the shapes produced by the drawingML import had
types like ooxml-triangle, and EnhancedCustomShapeTypeNames::Get() only
handles VML/binary MSO shapes (e.g. isosceles-triangle). Add an OOXML
mode, and in that case use msfilter::util::GETVMLShapeType() instead,
and only fall back to EnhancedCustomShapeTypeNames::Get() if necessary.
Change-Id: Ic93ba4719133dd3e96c17d2562642a03e559fefa
This can be used later for the VML or binary export of shapes imported
from drawingML. Note that without this, drawingML shapes won't be
exported to VML, as e.g. for a triangle it expects a
'isosceles-triangle' type, while the shype's type is 'ooxml-triangle'.
Change-Id: I59abc27febdd026c181a7ff38b16c93567058cb9
After the move now other classes can convert DateTime to OString also
Reviewed on:
https://gerrit.libreoffice.org/6816
Change-Id: I0ceb9a5cc26103a6cb36d7765a717770ec3fbe7d
