examining svx/source/unodraw/unoprov.cxx "Geometry" is a
indeed a drawing::PolyPolygonBezierCoords for the BezierShapes
and a drawing::PointSequenceSequence for the PolyShapes
regression since e44335abe0 because after
223f6b631c we started getting
drawing::PointSequenceSequences in maPath which is the wrong type for the
argument to property "PolyPolygonBezier" for those shapes. Which led me to
incorrectly assume that the all PolyPolygonBezier properties were named
"PolyPolygonBezier" which isn't the case.
so reverting the non maPath hunks of e44335abe0
Change-Id: I013a66778d11a472fc4567e53a9e17e73e2b91ce
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
Set to true for export, false for import. If export true, an
XMLPropertyMapEntry with mbImportOnly==true is not added to the
mappings. This to be able to have more than one mappings for import
(for example a current extension namespace and the future namespace
proposed to the ODF-TC, or corrected typos in element or attribute
names), but map only to one entry on export, of course.
Change-Id: Ia01ea949c88eda2f8a6c10f51c59e35e7abdcaf3
While exporting chart "crosses" position values were
not handled properly in chartexport.
Fixed this issue by handling "autozero" value for c:crosses.
Added unit test.
Change-Id: I3489908d4c3d4b41a04debfecf95e65f373649ce
Class XMLNumberWithAutoInsteadZeroPropHdl (which appears to be used only
for this attribute) needs to be adapted to the change that
"PageNumberOffset" value 0 is no longer invalid; use "void" value for
invalid instead, which appears more appropriate anyway.
Unfortunately the type of style:page-number is positiveInteger so
writing 0 would be invalid; write "auto" instead for now.
Change-Id: I9621ea201fd928087b863c562607c3d77a3b0269
...in comphelper::PropertyMapEntry and SfxItemPropertyMapEntry. And as the
arrays of such need to be initialized dynamically anyway, also change their name
members to proper OUStrings while at it. Plus some const clean-up.
Change-Id: I67d4d7b5773fb020605f369daf39528bec930606
This reverts commit 90f91088d2 for now:
Ach, old GCC doesn't like plain string literals to initialize members
of OUString type...
Change-Id: I50563a00406259bb5d41831e2a2796762450d097
...in comphelper::PropertyMapEntry and SfxItemPropertyMapEntry. And as the
arrays of such need to be initialized dynamically anyway, also change their name
members to proper OUStrings while at it. Plus some const clean-up.
Change-Id: I67d4d7b5773fb020605f369daf39528bec930606
The value written for an Impress time field is something like
text:time-value="0000-00-00T23:28:07" (in LO 3.5+) or
text:time-value="0-00-00T23:28:07" (in OOo 3.3) which contains an
invalid all-zero date. Such values are actually rejected by the
ODF import since commit ae3e2f1700.
Actually there was no real support to read the RelaxNG type
timeOrDateTime before.
So fix that by:
- adding convertTimeOrDateTime/parseTimeOrDateTime functions to
sax::Converter
- recognizing and ignoring the 2 invalid all-zero values written by
LO 3.5 and historic OOo respectively
- writing a bare "time" in text:time-value if the DateTime struct
contains zero Date members
(Older OOo versions and AOO cannot actually read that, but everything
they _can_ read is invalid ODF...)
Change-Id: I754076caee74a5163ed3f972af0f23796aa14f9f
In commit 363cc39717
"convert equalsAsciiL calls to startWith calls where possible"
I incorrectly converted equalsAsciiL calls to startsWith calls.
This commit fixes those places to use the == OUString operator.
Change-Id: If76993baf73e3d8fb3bbcf6e8314e59fdc1207b6
