Issue 108739 - API: Shear angle has mathematically wrong orinentation
Summary: API: Shear angle has mathematically wrong orinentation
Alias: None
Product: Draw
Classification: Application
Component: code (show other issues)
Version: DEV300m69
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Blocks: 94403
  Show dependency tree
Reported: 2010-01-28 14:39 UTC by Armin Le Grand
Modified: 2017-05-20 10:48 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Armin Le Grand 2010-01-28 14:39:33 UTC
AW: As in #i78696# for rptation angle, we have the same error for shear angles
whcih also needs to be corrected, at least for API and core.
Comment 1 Regina Henschel 2010-02-01 14:16:45 UTC
I'm working on this issue.
Comment 2 Armin Le Grand 2010-02-01 14:17:50 UTC
AW. Looking for all "ShearAngle" and "Transformation" usages again. For
transformation, i can also use #i78696# hints in comments...
Comment 3 Armin Le Grand 2010-02-09 14:52:09 UTC
AW: Creating a new CWS, this is too critical to mix with too much other stuff.
Removing task, preparing CWS...
Comment 4 Armin Le Grand 2010-02-12 13:39:44 UTC
AW: Basic problem are the implementations of TRGetBaseGeometry/TRSetBaseGeometry
and their usages. Initially, these methods were designed for having an
early-access matrix access to the shapes (drawing model). A current look shows
that the not easy conversions from the old DrawingLayer model data to/from
linear algebra transformations is not easy.
It also shows that TR(Get|Set)BaseGeometry was intended for API only usage:

(a) There is unit conversion to guarantee 1/100th mm which is only wanted in the
API and could even lead to errors in other usages. This needs to be moved to the
API usages of these methods.

(b) There is taking care of the Anchor, mostly a feature used from SW. This
feature should be completely removed from Drawinglayer and be completely handled
from SW.

Looking at (b) shows that there are already API implementations in SW which use
aggregation to handle the anchor changes at export, but none at import. Handling
these requires to change geometry data, e.g. polygons, matrices and points, all
in API format. This laeds to...

(c) create standard type converters as tooling in basegfx for UNO API classes
which correspond to basegfx classes like B2DPolygon, B2DPolyPolygon (curve and
non-curve), B2DHomMatrix, B2DPoint. Migrate all up-to-now distributed converters
in OOo code to tooling usage.

Thus (c) is a good start. Let's go...
Comment 5 Armin Le Grand 2010-02-12 18:50:20 UTC
AW: A lot of tooling added for (c) and done many replaces in svx, xmloff and sw.
Thus, (c) is making good progress. Also found some minor errors in API. Used the
chance to make one more conversion step with polygons independent from the old
integer-based tools Polygon/PolyPolygon. Checking build...
Comment 6 Armin Le Grand 2010-02-16 15:39:00 UTC
AW: The anchor problem (b) is really nasty and currently not completely
removable in SW. Base problem is that SW uses the DrawingLayer for visualisation
(d) and as model for draw shapes (e) at the same time. While (d) needs to have
the draw objects for SW relative to their anchor (which is also the API format
in SW and FileFormat), (e) needs to have the transformation needed for painting.
This cannot work cleanly in a single draw object which only has one
transformation. Thus, currently, a mix of both is used and works, but it is
unclear and dependent of the usage call which coordinate system we are in. This
needs to be cleaned up URGENTLY in one of the next versions, e.g. by having in
SW an explivcit DrawPage with the model DrawingLayer objects and copied from
that other pages with the visualisation DrawingLayer pages.
Trying to reduce (at least) the interface methods at SdrObject to a minimum...
Comment 7 Armin Le Grand 2010-02-23 16:14:25 UTC
AW: Completely added/implemented
getSdrObjectTransformation/setSdrObjectTransformation as replacement for
TRSet/GetBaseGeometry. Implementations take care of mirroring now. Completely
checked with own object types. The model unit change (TWIPS for SW) and the
anchor calculations are moved to the API implementations completely. The API
implementations use slightly different ways to do things.
One big change is that get/setSdrObjectTransformation does no longer return a
path added in scaled unit coordinates; this just went to problems and more
computing. Adaplted all XMLOFF object importers/exporters and the API adaptions
to use new functionality.

Also adapted the ShearX mirroring where needed (but that's the smallest part).

Now looking for SW's API usage since there, the anchor and relative point stuff
leads to big problems (as already described). ADded a patch from OD from CWS
sw33bf03 (#i108851#) which already corrects some problems in that direction.
Need to thoroughly test with SW with the applied changes...
Comment 8 Armin Le Grand 2010-02-25 11:07:37 UTC
AW: Done some corrections for SW, works so far. Removing TRSet/GetBaseGeometry,
cleaning up, building. Checked in and pushed that state.

Started some basic cleanups in SdrObject:
- move maBLIPSizeRectangle to SdrObjPlusData
- move mnNavigationPosition to SdrObjPlusData
- sort private/protected/public
- remove not needed friend declarations
- move sdr::ObjectUser and Sdr::PageUser mechanisms to standard
SfxListener/Broadcaster mechanism, fire SfxSimpleHint(SFX_HINT_DYING) for
SdrPage and SdrObject for implementing the same functionality
Comment 9 Armin Le Grand 2010-02-25 15:32:44 UTC
AW: Using SDrHint now, added types for Dying SdrObjects and SdrPages.
Looking deeper for anchor stuff now...
Comment 10 Armin Le Grand 2010-02-26 12:54:03 UTC
AW: I have now reduced the Anchor-Based methods

	//virtual void NbcSetRelativePos(const Point& rPnt);
	//virtual void SetRelativePos(const Point& rPnt);
	//virtual Point GetRelativePos() const;
	//void ImpSetAnchorPos(const Point& rPnt) { aAnchor=rPnt; }
	//virtual void NbcSetAnchorPos(const Point& rPnt);
	//virtual void SetAnchorPos(const Point& rPnt);
	//virtual Point& GetAnchorPos() const;

to a pair of 

    virtual void SetAnchorPos(const Point& rPnt);
    Point GetAnchorPos() const { return aAnchor; }

where the virtual is needed for group objects which assign the anchor to their
members (and to themselves, too).

Adaptions with deep analysises are through, build done and working. Adaptions
are needed in SW and SC.

SC used the anchor just for a hack (stored 0,1 in it as sign of page-anchored
object), moved that to a own ScFlag at SdrObject. There was another place which
used SetRelativePos, but since SC at no place ever set an anchor, this is
obsolete by chance.

SW uses the anchor a lot and there are quite some places to look at. Most of
them solve after analysis to a no-move (just anchor set), some of them to a
relative move. Adapted all of them, need to test thoroughly...
Comment 11 Armin Le Grand 2010-03-16 18:29:38 UTC
AW: Checked all transfer cases btw this and standard version, esp. SW in
RTL-Mode. Found a nasty problem with the start point of callouts, had to hunt
this for a while, but works now. Commited that stable version.
Comment 12 Armin Le Grand 2010-03-23 12:01:05 UTC
AW: Testing with the new implementations of get/setSdrObjectTransformation shows
many nifty problems which have to do with the non-abilities of the old core,
e.g. calling NbcMirror methods from SDrPathObj for the Text parts (to get the
weird text mirrroring running) has caveats which lead to double action;
SdrTextObj::NbcMirror will again change object geometry, thus
setSdrObjectTransformation should only change graphic content which would be the
mirroring of the polygon itself. If a SnapRect is to be set and from which
method is not easy to figure out with the old stuff involved. Sometimes, it just
is not possible to solve it due to old model limitations.

This brings me back to the 'big change': Give SdrObject a ObjectTransformation.
Implications, though, go very far...

To check what else is in the way (a and b from above are done) i change to isolate:
(d) aOutRect to maObjectBoundRectangle
(e) aAnchor to maObjectAnchor

It quickly shows that (d) is a hard case; aOutRect SHOULD be the BoundRect of
the object, but for naked SdrObject and derivations other than SdrAttrObj (which
gets maSnapRect) is is misused as object geometry as can be seen in the
manipulating and creating methods. The Move/Shear/Scale etc. would be removed
anyways, but the BegCreate etc. is in the way. Trying to isolate these into an
own tooling class...

Comment 13 Armin Le Grand 2010-04-14 13:28:38 UTC
AW: Investigated in getting rid of SdrVirtObj since it's only used in SW
anymore. Got pretty far, but is too dangerous; we need SW's model rework before
Comment 14 Armin Le Grand 2010-04-14 13:30:03 UTC
AW: Did further isolations/renamings in SdrObject as preparation for
transformation change. Still looking what else could be moved out of the way...
Comment 15 Armin Le Grand 2010-04-20 10:44:46 UTC
AW: Did a lot of deep experimenting (changing and building incompatible from
SVX). My current state is that there are things to do first:
(e) Cleanup messaging. This is mainly because of SdrObjUserCall (which mainly
SW, but also (and seems initially) SD uses for a completely different purpose.
Main problem here is that it's all a hack to call back with the BoundRect before
object change (which cannot be accessed after the change in a regular way, it's
gone with the change). SW needs this to know not only the new area where to
update the layout, but also the old area...
(f) Cleanup SdrVirtObj. It is only used by SW nowadays and not regularly at all.
It forces many methods to be virtual without the basic need. It is deprecated
and with the DrawModel changes in SW (which are at halt currently, sadly) it
will be no lonhger needed anyways. I experimented with migrating the rest of
needed functionality to SW, but a deeper analysis is needed...

Let's go...
Comment 16 Armin Le Grand 2010-04-20 10:47:43 UTC
AW: OOps, missed a letter. To not get confused (since d is the central point), it's:

(f) Cleanup SdrObjUserCall
(g) Cleanup SdrVirtObj
Comment 17 Armin Le Grand 2010-04-28 14:13:36 UTC
AW: (f) is good underway now. Users are SW, SD and dialogs in SVX. Every usage
is different, slowly adapting to standard SfxBroads´caster/Listener. There are
quite some caveats, thus i also need to test thoroughly all the time...
Comment 18 Armin Le Grand 2010-04-28 16:46:42 UTC
AW: (f) done, built and committed. Needs testing now. I'll have to play around
with the dialogs, SW and SD...
Comment 19 Armin Le Grand 2010-05-04 11:53:52 UTC
AW: Added (g), too. Checking SW for it. For (f), i have a crash in SD and some
dubious behaviours in SVX, need to track all of them down to keep (f,g)...
Comment 20 Armin Le Grand 2010-05-04 16:51:24 UTC
AW: (f) and (g) done, some minor glitches fixed.

On the next step i stumbled above the old habit that 3D objects all have a
SdrObjList where only a SdrScene (also used as group) needs one. This comes from
the times when the areas for the surfaces were represented as SdrObjects. Trying
to get rid of that...
Comment 21 Armin Le Grand 2010-05-05 10:48:10 UTC
AW: (h): Cleanup SdrObjList usage for 3D objects; only a E3dScene should have a
SdrObjList (E3dObjList in this case). Classically, all E3dObject(s) had one
since the very old version of the 3D engine created SdrObjects (2d polygons) for
all surfaces needed for 3d object visualisation and Z-sorted them.

AW: Cleanup in good progress....
Comment 22 Armin Le Grand 2010-06-08 10:24:42 UTC
AW: Adapted target
Comment 23 Marcus 2017-05-20 10:48:18 UTC
Reset assigne to the default "".