https://bugs.documentfoundation.org/show_bug.cgi?id=143377

Armin Le Grand <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|[email protected] |[email protected]
                   |desktop.org                 |

--- Comment #11 from Armin Le Grand <[email protected]> ---
Identified the problem:
In Cell::HelperCreateB2DHomMatrixFromB2DRange a Shear/Skew is applied depending
on the rotation. It is excluded for zero (IsRotated()) but not for
mfOrientation == 3.1415926535897931 which is 180 degree (PI).
Thus

  const double fSkew(aY.getY() * (cos(mfOrientation) / sin(mfOrientation)));

is created as -5.5526213800864256e+17 due to sin(mfOrientation) being close to
zero (numerical errors, it should be straight zero what would have led to
division by zero and a crash). This is HUGE.
The rest of the double-precision mechanism creates the correct borders for that
Skew, so what you see is the VERY far-stretched geometry of the border
polygons.

This makes of course no sense, so it needs to be handled for PI/180 deg
rotation. The text is drawn at ScOutputData::DrawRotated and use a Skew, too,
so we should do the same correction as it has to be there already.
Unfortunately it also just works by chance - the eRotMode gets forced to
SVX_ROTATE_MODE_STANDARD by

  if ( nAttrRotate == 18000_deg100 )
    eRotMode = SVX_ROTATE_MODE_STANDARD;    // no overflow

but still wild values for

                                    nCos = cos( nRealOrient );
                                    nSin = sin( nRealOrient );

get calculated, nSin (a double :-)) being also wild (1.2246467991473532e-16).
All calculations use it, but due to being close to zero, it has no real
influence -> nothing bad happens...

It *still* only corrects for 18000, not for 17999 nor for 18001, so we are
lucky that only single degree values pop in from the UI side (not sure about
UNO API or odf import...).

But it gives us no good hint how to correct it at
Cell::HelperCreateB2DHomMatrixFromB2DRange. Have to think about a good
solution...

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to