Now the page title field can finally be imported and displayed in
Impress \o/ It was a simple copy'n'pasta error, but damn, was it
hard to find ...
Change-Id: I04a3c71568960a66721269da3208208e168a99ac
if bAutoStyles is true then the mbDoSomething of the SvXMLElementExport is
false, and the ctor/dtor doesn't do anything so any attributes added to the
exporter are not cleared by the SvXMLElementExport dtor
so only add the attribute if bAutoStyles if false and might as well extend the
block to cover the use of SvXMLElementExport and use the other ctor which
defaults mbDoSomething on
Change-Id: If35cd35e902372562fd7e78b3f970d91fcec3c16
... for Writer frames, which were missing the draw:opacity; turns out
this is because now the the default valued properties are not exported
any more, which causes them to be missing in the property array so the
hard-coded indexes in XMLTextExportPropertySetMapper::handleElementItem()
do not find them.
(regression from c3e49660e7)
Change-Id: I84b6c09b23a2275161135290f1b0ac9f52546a80
Make sure that it does not confuse our importer by adding an attibute to
ignore it when the new elements have been added.
Change-Id: I15991be9dd993e2aeb18c440a14de3711f8001f4
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
draw:fill-gradient-name="" in the graphic properties now causes
BaseFrameProperties_Impl::FillBaseProperties() to fail and prevent
insertion of the SwXTextFrame.
(regression from 6e61ecd096)
Change-Id: I9b4f3ddb0f0e1b3a80e86bbdc1af2dade1c8edf7
ODF1.3 implement a new attribute for engineering notation
https://issues.oasis-open.org/browse/OFFICE-1828
This commit only add this attribute to ODF import/export.
Engineering notation is not yet available.
Treat also thousand separator with exponent-interval
Change XML_NAMESPACE_NUMBER to XML_NAMESPACE_LO_EXT for
exponent-interval
Change-Id: Ia18f9e150ca32aa9bbe133c082c3f9330e949f11
Reviewed-on: https://gerrit.libreoffice.org/14875
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
By running some tests, I noticed double wave didn't appear when opening report in non edit mode.
First you must know that to indicate "double wave", xml contains these 2 information:
style:text-underline-style="wave" style:text-underline-type="double"
The problem is the reading order of the parser doesn't seem the same each time.
So if it reads style then type, it's ok thanks to this part:
132 case awt::FontUnderline::DOUBLE:
133 // A double line style has priority over a bold line style,
134 // but not over the line style itself.
135 switch( eUnderline )
136 {
137 case awt::FontUnderline::SINGLE:
138 case awt::FontUnderline::BOLD:
139 break;
140 case awt::FontUnderline::WAVE:
141 case awt::FontUnderline::BOLDWAVE:
142 eNewUnderline = awt::FontUnderline::DOUBLEWAVE;
143 break;
but if the parser read type in the first place then style, the case FontUnderline "DOUBLEWAVE" wasn't managed
Change-Id: Ie090507898e537827eebaae157dfac248baa43f1
Reviewed-on: https://gerrit.libreoffice.org/14801
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
These are pretty silly anyway, but apparently it complains even about
integer variables which make this rather a waste of time.
Change-Id: I15e847d33d5decd2adcab04e4f1567d3997d28a2
