|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | API: Shear angle has mathematically wrong orinentation | ||
|---|---|---|---|
| Product: | Draw | Reporter: | Armin Le Grand <Armin.Le.Grand> |
| Component: | code | Assignee: | AOO issues mailing list <issues> |
| Status: | ACCEPTED --- | QA Contact: | |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | issues, rb.henschel |
| Version: | DEV300m69 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
| Issue Depends on: | |||
| Issue Blocks: | 94403 | ||
|
Description
Armin Le Grand
2010-01-28 14:39:33 UTC
I'm working on this issue. AW. Looking for all "ShearAngle" and "Transformation" usages again. For transformation, i can also use #i78696# hints in comments... AW: Creating a new CWS, this is too critical to mix with too much other stuff. Removing task, preparing CWS... 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... 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... 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... 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... 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 ... AW: Using SDrHint now, added types for Dying SdrObjects and SdrPages. Looking deeper for anchor stuff now... 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...
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. 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... 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 this... AW: Did further isolations/renamings in SdrObject as preparation for transformation change. Still looking what else could be moved out of the way... 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... AW: OOps, missed a letter. To not get confused (since d is the central point), it's: (f) Cleanup SdrObjUserCall (g) Cleanup SdrVirtObj 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... AW: (f) done, built and committed. Needs testing now. I'll have to play around with the dialogs, SW and SD... 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)... 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... 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.... AW: Adapted target Reset assigne to the default "issues@openoffice.apache.org". |