Created attachment 43501 [details]
testkit demonstrating the problem

release_blocker due to dataloss

Can confirm that problem on another PC with 2.2RC2 installation from the same
install.exe

Reproducible. Reassigned. Talking to developer if this is really a stopper.

Until now I unfortunately failed to create a new simple drawing (with 2.0) that
shows the effect in 2.2.
The common criterion of all shapes showing that problem seems to be that they
contain elements that have been created by rotating or mirroring of a copy of an
other element.

This is a showstopper. Reassigned.

added md to cc

Ok in OOF680m5, broken in OOF680m6.

Created attachment 43523 [details]
presentation showing similar problem

attached presentation has some graphic elements at the bottom line of the
master. Open with 2.2RC1 / RC2 -> most of those elements are missing

AW: Thanks for the example, it leaded to the cause. Problem is a change in
basegfx which was in from m2 to m5 (no more in m6) which changed handling of
decompose so that no negative scalings were accepted (negatibe scale in x and y
equals a 180 degree rotation). The example was written using a m5, so it was
using an in-between version.
I already checked with X/Y mirrored objects and 180 degree rotated PolyPolygon
objects export and import with m10, works.

AW->andreasschnabel: How did You create the objects in question? Looks like they
were either mirrored in X and Y or rotated by 180 degrees once. Tried to
reproduce, but could not yet.

AW: BTW: aw047 created on oofm10, building some stuff with debug, looking at
installed m10...

andreschnabel->aw:
If the reported bug was caused by an inbetween version, my example is different.
The example is a very old file (converted from 1.1 template). I'll try to
reproduce the steps and file a new issue.

AW: The bug happens with one special state of the transfpormtion of objects,
when they are rotated 180 degrees or mirrored in X and Y (scale is negative in X
and Y). This is one state since it is equal in transformation specification.
The bug was caused by transformation handling in DrawingLayer methods
::TRSetBaseGeometry because they were not prepared to work with the X and Y
scale negative case. Generally, the old model parts of the DrawingLayer are not
able to handle this, so it needs to be solved/handled when filling the old model
data structures (GeoStat, Rectangle). This will no longer be needed once these
objects will handle a transformation directly, we are on the way to that goal.
Concretely the problem came in with aw024 where i simplified filling GeoStat
using the new basegfx data classes. That simplification went too far in ignoring
the above mentioned case.
Thankfully someone extern had a test case where an object is mirrored in X and Y
and where this happens (not always, depends on numerical questions, too). It
would only happen very rarely and did not happen internally until now. That's
also the reason i could not really simply reproduce this case.

Solution: In TRSetBaseGeometry, look for Scale.getX() and scale.getY() < 0.0 and
react in changing to the 180 degree rotation in that case. Testing...

AW: Okay, works. Checked in, updated on CWS, building...

AW: Set to fixed, instsets buiding...
AW: RT is informed, too...

AW: unxlngi6.pro and unxsols4.pro ready, wntmsci10.pro stopped (grrr...).
AW: Okay, wntmsci10.pro done now. Ready for QA.

Verified in CWS.

Reassigned to me.

found the issue fixed in OOo2.2RC3 for both test files -> closed

Ok.

This bugfix for "2.2.0RC3  Multilanguage/German version WIN XP:
[680m11(Build9129)]" does not solve the entire problem. Today I was editing a
drawing with a.m. version and suddenly I saw the crippled symbol groups again.

I can not reproduce the problem with my "testkit.zip", but it's 1000%
reproducible with another document containing similar symbols, so that I was
able to create a sample document.

Steps to reproduce:

1. Open document "sample_b.odg" using RC3
2. save without any edit under new name
3. reopen 
   expected: all shapes look as before
   actual: only the old known symbol from "example_a.odg" still looks fine, all 
           other ones are damaged.

I will contribute a file with more samples, but unfortunately it will take
several time.

Created attachment 43799 [details]
Testkit: Additional comments from rainerbielefeld Mon Mar 19 14:56:30 +0000 2007

MD->rainerbielefeld: Can't reproduce this on an OOF680m13 running on Linux.

But I can, with m13 on Windows and Linux. I have already asked aw to have a look.

AW: Grrr, somehow my 1/2 side description from yesterday did not make it to the
database. So here we go once more...

AW->rainerbielefeld: Ideed, can reproduce. The core here is that You have used
short lines which are polygons (three points in a row) and are mirrored in X or
Y. Also necessary again is that the file is written with a m5 version (where the
temp change in matrix decompose was included, see above). Thanks for finding that!

AW: When You look above i fixed a problem when X and Y are both mirrored (scale
is negative) and that fix works fine. What i did not take into account are
objects where only one (X or Y) is mirrored and thus only one scale is negative.
This happens in practice only with files written between m2 and m5, but may also
be constructed by another application using OpenDocument. It's a legal
definition and needs to be handled.
Source of the problem is that for historical reasons
SdrPathObj::TRSetBaseGeometry does not get the polygon data as unit polygon
(scaled to 0.0 -> 1,1) but in scaled form. The API and the polygons simply could
only handle integers. Thus, the scale is implicitely applied to the polygon
already, but not the mirooring. Thus, when scale X or Y is negative, the polygon
needs to bve mirrored accordingly (multiply by -1.0).
AW: Added these to test, works.
AW: Creation CWS aw049, adding svx...

AW: BTW: It's a load error, the created files are not corrupted. It needs to be
fixed but only happens with files wriiten between m2 and m5. Nonetheless needs
to be fixed since negative scale definitions are allowed in the file format.

@aw:
Your statements is 100% conform with the results of my own tests, I cant't find
any other problem than this "special polygon problem".

AW: Added to aw049, commited.
AW: Building install sets. Fixed.

AW->WG: Please verify.

Verified in CWS on Win, Lin, Sol.

Tested in m14 under lin, win. Closed.