[Libreoffice-bugs] [Bug 131275] Fileopen DOCX: Organigram wrong again

[bugzilla-daemon at bugs.documentfoundation.org]

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

Timur <gtimur at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|bibisectRequest             |bibisected, bisected
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Timur <gtimur at gmail.com> ---
a35ab2611687602ed7c0b9856f2ced2278e31112 is the first bad commit
commit a35ab2611687602ed7c0b9856f2ced2278e31112
Author: Jenkins Build User <tdf at pollux.tdf>
Date:   Mon Jul 2 18:38:24 2018 +0200

    source sha:36bade04d3780bc54c51b46bb0b63e69789658a5

Previos commit b47996947c116b1a7b30f6e1352b40aac068cb0c (HEAD,
refs/bisect/good-b47996947c116b1a7b30f6e1352b40aac068cb0c)
Author: Jenkins Build User <tdf at pollux.tdf>
Date:   Mon Jul 2 17:20:22 2018 +0200

    source sha:942f1056b51e53358d42ff8da8a1bbdce9ba5303

Single source:

commit  36bade04d3780bc54c51b46bb0b63e69789658a5        [log]
author  Armin Le Grand <Armin.Le.Grand at cib.de>  Thu Jun 28 19:48:59 2018 +0200
committer       Armin Le Grand <Armin.Le.Grand at cib.de>  Mon Jul 02 18:03:44
2018 +0200
tree    c4465bf33aa2cda65511a2c094688522e9c9b43a
parent  942f1056b51e53358d42ff8da8a1bbdce9ba5303 [diff]

tdf106792 Get rid of SvxShapePolyPolygonBezier

SvxShapePolyPolygonBezier was an implementation for the UNO
Shape group of polygons with bezier parts (filled/unfilled/
closed/open), e.g. com.sun.star.drawing.OpenBezierShape.
It was differing from SvxShapePolyPolygon just by supporting
drawing::PolyPolygonBezierCoords instead of the simple
drawing::PointSequenceSequence and some details.
This leads to problems - the ShapeType *does change* e.g.
when you edit a non-bezier Shape in Draw/Impress and change
parts to curve (also when closing, see ShapeTypes above).
This is why SvxShape::getShapeType() already detects this
identifier by using thze internal ShapePolyType (e.g.
OBJ_PATHLINE).
So there is no reason to have two separate UNO API imple-
mentations for sthe same type of SvxShape at all. Get rid
of the extra one and unify this implementation detail.
Also cleaned up double basegfx tooling for conversions of
UNO API Poly/bezier data and B2DPolygon.
Adapted test for "tdf113946.docx", see comment there.
Adapted test for "tdf90097.rtf", see comment there. Also
needed to use the Linux values, also check comment there.
Adapted test for "tdf105127.docx", see comment there.
Adapted test for "tdf85232.docx", see comment there.
Had to fic a problem with test for "tdf96674.docx"- the
adaption of the RotateAngle for line objects goes havoc
together with the UNO API when scaling is involved. That
old aGeo rotate stuff just kills the existing rotation due
to numerical inprecise stuff. The UNP API - in trying not
just to apply a rptation, but manipulate the existing one
then goes wrong in not re-getting the current rotation
value anymore. ARGH! This is the original reason for the
ols tdf#96674 task - i doubt that the additional code to
make a line not exactly hor/ver is needed.
Checked and it is not needed, thus removed the change from
tdf#96674 in shape.cxx.

Change-Id: I2bb8d4cfe33fee3671f3dad60e5c18609a394f9d
Reviewed-on: https://gerrit.libreoffice.org/56614
Tested-by: Jenkins
Reviewed-by: Armin Le Grand <Armin.Le.Grand at cib.de>



New by bibisect. But this source is mentioned in:

bug 118693      bug 96640       bug 127555      bug 122717       bug 127370     
and duplicate in bug 127364
from fix in bug 106792  

So, likely a duplicate.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200311/bfc11bbc/attachment.htm>