me at siqi.fr
Tue Oct 8 11:27:46 PDT 2013
I've been investigating on this issue and I've tried the patch from Julien
and it still doesn't seem to fix the problem. There unit test always fails
on the equality assertion even if we reverse that as well.
Here is what I've got:
When we check against sal_Int32(0xD99594) (i.e. 14259604 in decimal) for
start color aGradient.StartColor
equality assertion failed
- Expected: 14259604
- Actual : 12603469
and When we check against sal_Int32(0xC0504D) (i.e. 12603469 in decimal)
for start color aGradient.StartColor
equality assertion failed
- Expected: 12603469
- Actual : 14259604
That is, whenever we reverse the hex value (the expected value) for the
unit test, the actual value coming out of the test is surprisingly reversed
as well!! Which I failed to explain...
I have to assume that there are other filters that are tested against this
unit test (which in this case needs to reverse the startColor/endColor as I
have done in the ooxmlexport filter) or there are some hidden mechanism in
this unit test that changes the actual value when we change the expected
My previous patch was tested (on OSX so without unit tests) during the
Milano hackathon and it has solved an interoperability bug so presumbly we
should keep this patch. Now I guess we need some qa experts to shed some
light on the mechanism of this unit test ...
2013/10/7 Siqi Liu <me at siqi.fr>
> Hello all,
> Sorry for the late response! This was a patch that I've submitted during
> the hackathon in Milan and it fixes the #fdo65295 on bugzilla.
> Actually we've analyzed the content of the .docx exported by writer and it
> seems that the startColor and the endColor were accidentally reversed so
> that each time we import and export a docx with gradient background, we
> reverse the start and end color in the exported .docx file.
> I would test the patch above to see if that solves the problem when I'm
> back home.
> Sorry for the broken build :P
> 2013/10/6 julien2412 <serval2412 at yahoo.fr>
>> If StartColor and EndColor have been reversed, perhaps it was the same for
>> qa part? So what about this patch?
>> diff --git a/sw/qa/extras/ooxmlexport/ooxmlexport.cxx
>> index f771ef9..8fdb7fb 100644
>> --- a/sw/qa/extras/ooxmlexport/ooxmlexport.cxx
>> +++ b/sw/qa/extras/ooxmlexport/ooxmlexport.cxx
>> @@ -733,8 +733,8 @@ void Test::testTextframeGradient()
>> getProperty<drawing::FillStyle>(xFrame, "FillStyle"));
>> awt::Gradient aGradient = getProperty<awt::Gradient>(xFrame,
>> - CPPUNIT_ASSERT_EQUAL(sal_Int32(0xC0504D), aGradient.StartColor);
>> - CPPUNIT_ASSERT_EQUAL(sal_Int32(0xD99594), aGradient.EndColor);
>> + CPPUNIT_ASSERT_EQUAL(sal_Int32(0xD99594), aGradient.StartColor);
>> + CPPUNIT_ASSERT_EQUAL(sal_Int32(0xC0504D), aGradient.EndColor);
>> CPPUNIT_ASSERT_EQUAL(awt::GradientStyle_AXIAL, aGradient.Style);
>> View this message in context:
>> Sent from the Dev mailing list archive at Nabble.com.
>> LibreOffice mailing list
>> LibreOffice at lists.freedesktop.org
> Siqi LIU
> Étudiant Ingénieur, 1ère année
> École Supérieur d'Électricité (Supélec)
Étudiant Ingénieur, 1ère année
École Supérieur d'Électricité (Supélec)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LibreOffice