Created attachment 69955 [details] Screenshots comparing LibO 3.6 with 3.7 Steps how to reproduce with parallel installation of Master "LOdev 3.7.0.0.alpha0+ - ENGLISH UI / German Locale [Build ID: 70ec82)]" {tinderbox: @16, pull time 2012-11-09 00:53:19} on German WIN7 Home Premium (64bit) with separate User Profile for Master Branch: 0. Download Attachment 66562 [details] of Bug 54447 1. Open sample document from LibO start Center Expected: looks like in WORD (See attachment 66560 [details]) Actual: See attached screenshot, all text frames seem lost 2. rightclick first of the invisible text frames in Navigator pane, 'Text Frame -> Edit -> Background -> Yellow -> <ok> Now you see all the page in yellow, so I think the frame fills complete page. 3. Go to "Type" Tab of dialog You see it's even worse, for me test frame size is 182.92cm x 91.48cm 5. Try to reduce size to 4cm x 3cm > That will not work Looked much better with 3.6.3
Same problem with Attachment 51225 [details] of Bug 54447
Confirmed as cross-platform bug and regression: also REPRODUICBLE on Mac OS X 10.6.8 (Intel) with LOdev 4.0.0.0.alpha0+ (Build ID: 32315e; pull time: 2012-11-13 00:32:26). If I open the .docx file from attachment 66562 [details], it looks just like on Rainer’s screenshot (all text frames seem lost). Not yet reproducible with LOdev 3.7.0.0.alpha0+ (Build ID: 88e457; pull time: 2012-11-08 04:14:44) on the same machine. With this daily build, the same .docx file still displays more or less exactly as in LibO 3.6.3.2 (see Rainer’s screenshot again). Time frame in which the bug was introduced: I can not test any master builds between the two mentioned above (Mac OS X master builds from 2012-11-10, 2012-11-11, and 2012-11-12 do not work at all, due to bug 57051), but it seems clear that this bug must have been introduced between 2012-11-08 04:14:44 (.docx file still displays correctly according to my test) and 2012-11-09 00:53:19 (all text frames seem lost according to Rainer’s test). So a fairly limited count of commits to check?!
I can confirm. My LO version even CRASH when I try to open https://bugs.freedesktop.org/attachment.cgi?id=69955 (I'll add attachment soon). LibreOffice Version 4.0.0.0.beta1 (Build-id: 87906242e87d3ddb2ba9827818f2d1416d80cc7) TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: 2012-12-05_22:13:37 with Dutch Language pack; Installed on a Mac OS X 10.8.2. Even a simple frame saved as a .docx will result in a text frame that cover the whole page. How to reproduce: * Create a frame with a background color (for example green) and a border in Microsoft Word * save document as .docx * Close Microsoft Word * Open file with LibreOffice 4.0 beta 1 (I'll upload this .docx test file as attachment.) Result: the frame covers the whole page. Page is now filled with the background color of the frame we created in step 1. This is a REGRESSION, because the file opens correctly in LibreOffice 3.6.4.3 (Build-id: 2ef5aff) (also Dutch Language Pack and Mac OSX ...) Even frames with text in it, created with LibreOffice 3.6.4.3 and LO 4.0 Beta 1, and saved as .docx will result in a page without a frame. The text isn't gone (just not in a frame anymore). I think there is a serious problem with frame-handling in LibreOffice, with a regression for LO4.0.
Created attachment 71398 [details] Crash report when I try to open attachment of first post
Created attachment 71399 [details] Test file created with Microsoft Word (for mac 2011) See comment 3
I've tested 4.0 Beta2 on Windows 7 x64 with * attachment 66562 [details] (comment 0) * attachment 51225 [details] (comment 1) * attachment 71399 [details] (comment 5) They all looks much better than beta1, also more similar to 3.6.3. All, please test again with Beta2, so we can close this as WORKSFORME. Thanks :)
Thanks for retesting it with LO 4.0 b2 Korrawit Pruegsanusak! I can confirm it works with LibreOffice 4.0.0.0.beta2 (Bouw-id: 4104d660979c57e1160b5135634f732918460a0) TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: 2012-12-18_17:13:13 So -> RESOLVED (WORKSFORME)