Issue 75086 - Dataloss: Drawings created with 2.0 corrupted
Summary: Dataloss: Drawings created with 2.0 corrupted
Alias: None
Product: Draw
Classification: Application
Component: open-import (show other issues)
Version: OOo 2.2 RC2
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 2.2
Assignee: wolframgarten
QA Contact: issues@graphics
Keywords: regression, release_blocker
Depends on:
Blocks: 73858
  Show dependency tree
Reported: 2007-03-03 12:04 UTC by Rainer Bielefeld
Modified: 2007-03-22 11:23 UTC (History)
5 users (show)

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

testkit demonstrating the problem (31.09 KB, application/x-compressed)
2007-03-03 12:06 UTC, Rainer Bielefeld
no flags Details
presentation showing similar problem (24.44 KB, application/vnd.oasis.opendocument.presentation)
2007-03-05 10:41 UTC, andreschnabel
no flags Details
Testkit: Additional comments from rainerbielefeld Mon Mar 19 14:56:30 +0000 2007 (10.51 KB, application/
2007-03-19 16:10 UTC, Rainer Bielefeld
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2007-03-03 12:04:11 UTC
I checked with "2.2.0RC2  Multilanguage/German version WIN XP:
[680m9(Build9124)] and saw that several elements in  drawings created with OOo
2.0 are shown crippled (180°turned around the bottom right corner of the
original element). More details you can see in "example.odg" and
"screenshots.png" from my "". 

That was OK with 2.1, new problem with 2.2!

The drawing will be destroyed if it has been saved 1 times with 2.2, if you
reopen the drawing with 2.1 or 2.0 the crippled view from 2.2 will reappear

I can supply several more examples for drawings crippled by 2.2 if necessary.

I believe this is a blocker for 2.2 final.
Comment 1 Rainer Bielefeld 2007-03-03 12:06:14 UTC
Created attachment 43501 [details]
testkit demonstrating the problem
Comment 2 Rainer Bielefeld 2007-03-03 12:07:30 UTC
release_blocker due to dataloss
Comment 3 Rainer Bielefeld 2007-03-04 13:49:35 UTC
Can confirm that problem on another PC with 2.2RC2 installation from the same
Comment 4 wolframgarten 2007-03-05 08:23:01 UTC
Reproducible. Reassigned. Talking to developer if this is really a stopper.
Comment 5 Rainer Bielefeld 2007-03-05 09:11:22 UTC
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.
Comment 6 wolframgarten 2007-03-05 09:26:26 UTC
This is a showstopper. Reassigned.
Comment 7 mdxonefour 2007-03-05 09:48:03 UTC
added md to cc
Comment 8 wolframgarten 2007-03-05 10:27:58 UTC
Ok in OOF680m5, broken in OOF680m6.
Comment 9 andreschnabel 2007-03-05 10:41:52 UTC
Created attachment 43523 [details]
presentation showing similar problem
Comment 10 andreschnabel 2007-03-05 10:43:21 UTC
attached presentation has some graphic elements at the bottom line of the
master. Open with 2.2RC1 / RC2 -> most of those elements are missing
Comment 11 Armin Le Grand 2007-03-05 12:04:18 UTC
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...
Comment 12 andreschnabel 2007-03-05 12:20:37 UTC
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.
Comment 13 Armin Le Grand 2007-03-05 14:20:02 UTC
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...
Comment 14 Armin Le Grand 2007-03-05 14:36:23 UTC
AW: Okay, works. Checked in, updated on CWS, building...
Comment 15 Armin Le Grand 2007-03-05 14:42:58 UTC
AW: Set to fixed, instsets buiding...
AW: RT is informed, too...
Comment 16 Armin Le Grand 2007-03-05 18:16:42 UTC
AW: and ready, stopped (grrr...).
AW: Okay, done now. Ready for QA.
Comment 17 wolframgarten 2007-03-05 20:27:18 UTC
Verified in CWS.
Comment 18 wolframgarten 2007-03-06 09:26:59 UTC
Reassigned to me.
Comment 19 andreschnabel 2007-03-07 20:21:34 UTC
found the issue fixed in OOo2.2RC3 for both test files -> closed
Comment 20 wolframgarten 2007-03-08 07:56:49 UTC
Comment 21 Rainer Bielefeld 2007-03-19 15:56:30 UTC
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 "", 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.
Comment 22 Rainer Bielefeld 2007-03-19 16:10:05 UTC
Created attachment 43799 [details]
Testkit: Additional comments from rainerbielefeld Mon Mar 19 14:56:30 +0000 2007
Comment 23 mdxonefour 2007-03-19 16:25:10 UTC
MD->rainerbielefeld: Can't reproduce this on an OOF680m13 running on Linux.
Comment 24 wolframgarten 2007-03-19 16:34:02 UTC
But I can, with m13 on Windows and Linux. I have already asked aw to have a look.
Comment 25 Armin Le Grand 2007-03-20 11:30:29 UTC
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...
Comment 26 Armin Le Grand 2007-03-20 11:35:54 UTC
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.
Comment 27 Rainer Bielefeld 2007-03-20 13:45:01 UTC
Your statements is 100% conform with the results of my own tests, I cant't find
any other problem than this "special polygon problem".
Comment 28 Armin Le Grand 2007-03-20 15:08:07 UTC
AW: Added to aw049, commited.
AW: Building install sets. Fixed.
Comment 29 Armin Le Grand 2007-03-21 11:07:25 UTC
AW->WG: Please verify.
Comment 30 wolframgarten 2007-03-21 11:34:16 UTC
Verified in CWS on Win, Lin, Sol.
Comment 31 wolframgarten 2007-03-22 11:23:28 UTC
Tested in m14 under lin, win. Closed.