Bug 48136 - FORMATTING: Subtract objects (Shapes -> Subtract) are modified after loading file
Summary: FORMATTING: Subtract objects (Shapes -> Subtract) are modified after loading ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 48122 52058 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-31 14:57 UTC by Johann
Modified: 2013-12-04 20:53 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Stored and loaded object that was created using subtract (7.83 KB, image/png)
2012-03-31 14:57 UTC, Johann
Details
Drawing (odg) where the issue appears (after open + save + re-open) (8.52 KB, application/vnd.oasis.opendocument.graphics)
2012-05-18 05:03 UTC, Rainer Matischek
Details
Drawing (pdf v1) where the issue appears (*before* saving+re-open) (7.63 KB, application/pdf)
2012-05-18 05:05 UTC, Rainer Matischek
Details
Drawing (pdf v2) where the issue appears (*after* saving+re-open) (7.63 KB, application/pdf)
2012-05-18 05:06 UTC, Rainer Matischek
Details
Drawing older version: Strange, this one looked "wrong" in LO351 but correct in LO3532 and it gets again "damaged" after just saving with LO3532 (8.54 KB, application/vnd.oasis.opendocument.graphics)
2012-05-18 11:29 UTC, Rainer Matischek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johann 2012-03-31 14:57:50 UTC
Created attachment 59318 [details]
Stored and loaded object that was created using subtract

Problem description: 
Objects that have been created using "Shapes -> Subtract" function are modified after loading file with LibO 3.5.1

This regards files created by LobO 3.3.4 and opened by LibO 3.5.1.

Steps to reproduce:
1. create in a new Drawing a big Rectangle.
2. create second smaller Rectangle and place it in the center of the big Rectangle.
3. now select both Rectangles and chose "Shapes -> Subtract"
4. Save Drawing and quit LibO.

Current behavior:
Open previous saved Drawing and you will see that the smaller Rectangle is not in the center of the big one.

If opening the same Drawing with version LobO 3.3.4 so the object is correct.

Expected behavior:
Created object should not be modified.
 

Platform (if different from the browser): 
              
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11
Comment 1 Regina Henschel 2012-04-01 15:13:22 UTC
*** Bug 48122 has been marked as a duplicate of this bug. ***
Comment 2 Rainer Bielefeld Retired 2012-04-05 07:18:52 UTC
<https://bugs.freedesktop.org/page.cgi?id=fields.html#status>
we should used FIXED only if a known fix has solved the problem; if the problem only disappeared without known reason, please use WORKSFORME.
Comment 3 Rainer Matischek 2012-05-18 03:41:46 UTC
The issue is still NEITHER fixed, NEITHER worksforme!

Reason:
After upgrading to Ubuntu 12.04 I've now tested this issue again with the newer version: "LibreOffice 3.5.3.2".

Result:
The issue still exists, but is now minimally diferent:
First, when I open the odg-file, which was saved in "LibO 3.5.1" and displayed wrong in "LibO 3.5.1" it *first* looks fine in "LibO 3.5.3.2".
(This might be the reason why someone might confirmed worksforme...)

*However*, after re-saving the file in "LibO 3.5.3.2" and re-opening in "LibO 3.5.3.2", the inner circle appears moved again!

Best regards,
Rainer
Comment 4 Rainer Bielefeld Retired 2012-05-18 03:55:44 UTC
Observations in Comment 2 NOT reproducible with "LibreOffice 3.5.4.1 (RC1) German UI/Locale [Build-ID: 7306755-f4f605c-738527d-1cf4bc1-9930dc8] on German WIN7 Home Premium (64bit) 

@Rainer Matischek
Please give reasons for WONTFIX Status selection!
Comment 5 Rainer Matischek 2012-05-18 05:03:49 UTC
Created attachment 61795 [details]
Drawing (odg) where the issue appears (after open + save + re-open)
Comment 6 Rainer Matischek 2012-05-18 05:05:12 UTC
Created attachment 61796 [details]
Drawing (pdf v1) where the issue appears (*before* saving+re-open)
Comment 7 Rainer Matischek 2012-05-18 05:06:24 UTC
Created attachment 61797 [details]
Drawing (pdf v2) where the issue appears (*after* saving+re-open)
Comment 8 Rainer Matischek 2012-05-18 05:27:47 UTC
For better documentation/reproducability I uploaded an example odf-file corresponding to the issue + 2 pdfs which show the figure before (how the figure should look like) and after saving, using LibO 3.5.3.2.

I'm sorry, I don't know exaclty to *which* status to change this issue from formal perspective (if "wontfix"or "reopened")...

What I can tell/tested is the following:
- According to https://bugs.freedesktop.org/show_bug.cgi?id=48122#c1 the issue should alredy be fixed in LO3.5.2.
- And now, afer Upgrading my Ubuntu to 12.04, I again observed that the issue is still reproducable in "LibO 3.5.3.2", which is now the default latest version in Ubuntu 12.04 LTS...

So, *if* this issue might be reproducable by other users using Ubuntu 12.04 LTS (=LibO 3.5.3.2), then there might be many other people effected by this issue...
Comment 9 Rainer Bielefeld Retired 2012-05-18 06:43:23 UTC
There is something a little suspect: In the MS File Explorer preview reporter's document shows the eyelet at it's correct place, but when I open the document, the eyelet is outside the other shape. That effect with all my version starting with OOo 3.2

I am not able to reproduce the problem with "Bug 48122 - FILESAVE: After saving inner position of a combined curve-object moves" attachment 59310 [details]

@Rainer Matischek:
I need a correctdocument.odg and a version number where that correctdocument.odg is shown correctly.
Comment 10 Rainer Bielefeld Retired 2012-05-18 08:41:33 UTC
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Has been observed with WIN and Linux, so OS ALL
Comment 11 Rainer Matischek 2012-05-18 11:29:41 UTC
Created attachment 61814 [details]
Drawing older version: Strange, this one looked "wrong" in LO351 but correct in LO3532 and it gets again "damaged" after just saving with LO3532
Comment 12 Rainer Matischek 2012-05-18 11:50:14 UTC
I'm sorry, I checked all my old drawings, but I don't have any older comparable examples which looked ok in an older LO version. (That's because I've drawn this special figure when I already used LO351 and then detected the issue...)

*BUT* in my data-snapshots I've found an older version of attachment "61795", which I originally have saved with LO351 --> I uploaded this older version now as "61814".

This file "61814" now behaves strange (at least in my ubuntu 11.04 and 12.04 systems):
a) I remember that exaclty this odg-file looked *wrong* when opened in LO351 (the circle was within the other shape, but MOVED out from the vertical center)
b) What's strange is that this odg-file *first* lookes *correct* when I now open it in LO3532
c) *BUT* finally, it gets again *damaged* after just saving with LO3532 (no changes, just "save as", the re-open in LO3532 and then the circle is outside of the other shape)

So I hope I can help with this information to reproduce the issue...

BR,
Rainer
Comment 13 Rainer Bielefeld Retired 2012-05-18 23:29:51 UTC
I was able to reproduce a wrong looking shape with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) and attachment 61814 [details]: The eyelet is 25mm too far to the right and 10mm too far to the top of the page. That matches with Rainer Matischek's observations.

With 3.5.3 everything looks fine, so I still can't see any problem with a current Version and set Status back to WFM

(In reply to comment #12)
> So I hope I can help with this information to reproduce the issue...

Currently I can't see any problem in a current version, but may be this issue is one of those what comes and goes? Please keep on checking with attachment 61814 [details], and if you see the problem for that document reappearing with 3.5.4 or later, please submit a new bug with a reference to this bug here and add me to CC.
Comment 14 Urmas 2012-07-14 07:39:00 UTC
*** Bug 34611 has been marked as a duplicate of this bug. ***
Comment 15 Urmas 2012-07-14 07:39:19 UTC
*** Bug 52058 has been marked as a duplicate of this bug. ***