Created attachment 120280 [details] Example Please load the example. Scroll to the end to find screenshots of the problem. Normally the jumping of the pictures in this document is not reproducible. But there is a trick to force it: Take the first picture in this document and delete it without deleting the frame. Now press Ctr+Z to undo. You see, that the pictures don't get back to their original places. Often the pictures are new arrange if your click the button "printer preview". This is not correct at all.
Comment on attachment 120280 [details] Example >PK¨NeG^Æ2''mimetypeapplication/vnd.oasis.opendocument.textPK¨NeGConfigurations2/statusbar/PK¨NeGConfigurations2/toolbar/PK¨NeG'Configurations2/accelerator/current.xmlPKPK¨NeGConfigurations2/floater/PK¨NeGConfigurations2/images/Bitmaps
Comment on attachment 120280 [details] Example No File
The content of attachment 120280 [details] has been deleted for the following reason: Uploader request
Thanks for reporting. ANd I would be interested in a test file, Jens. I think I can recognize / confirm the problem. Cheers - Cor
Created attachment 120315 [details] Example 2 The first example was retired.
Thanks jens, however I cannot confirm the issue with the sample document. ...
Fails for me exactly as described in comment #1 using version 5.03.2 under Linux. I have other documents where the same type of behavior has been observed. This is not a corner case unless using graphics and frames is considered a corner case. It sometimes takes a lot of work to get your graphics or frames to not move around on you after closing and re-loading, or as in this case, just deleting and undoing.
New per comment 8.
Version: 5.0.6.3 Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa Locale: de-DE (de_DE) While working on a book project (360pages and including pictures) and I had this problem too. I observed the following random behaviour: Loading the same document several times the page count was sometimes 352 (correct) and sometimes 354(incorrect). When looking at the document a blank page was inserted before a picture occupying an entire page. Since I work with even and odd pages later on another blank page was forced. To remove the undesired blank page I did the following: At the end of the partially filled page before the picture I added (!) another paragraph - just pressing enter - and strange enough the picture snapped back to its place and the empty pages disappeared. Unfortunately I have no example to reliably reproduce the problem.
(In reply to Buovjaga from comment #9) > New per comment 8. This issue is not clearly described.
(In reply to Cor Nouws from comment #11) > (In reply to Buovjaga from comment #9) > > New per comment 8. > > This issue is not clearly described. Well, I can reproduce it with the undo procedure outlined in the description. The result is exactly like in the "it often looks like this screenshot or similar" case in attachment 120315 [details]. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: 2d2a33934ecb952433a635ce5dab76cb2837b8a0 CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on June 9th 2016
Ah thanks :)
still this odd Whiteboard tag ;)
Created attachment 125587 [details] how to access testcase - first 50 pages of book Whith his file the problem showed up reproducibly in two tries. Steps to reproduce: 1. load the testcase file Ehrenbuch-Interior-V7c_P1-50.odt # due to upload restriction I provide this file indirectly in my dropbox - see details in attachment Unable-to-attach.txt. # pagecount should be (Incorrect value) 50 2. use navigator to position on page 27 # you will be positioned on page 28 ! 3. Scroll back to see page 27 # You should find page number 27 in the footer but no paragraph-End on this page. The page is empty but the repro now on page 28 should be on this page. 4. Position the cursor after the last character on page 26 (after "gestiftet.") 5. Press enter (create new but empty paragraph on page 26 # the picture snaps back from page 28 to page 27, the total number of pages is reduced to 49 6. Press undo # the initial state is not restored, the empty paragraph on gage 26 is removed, the total page count is 49, the document is flagged unmodified. 7. close the document (no save is suggested) 8. It should be possible to repeat above steps 1ff.
Created attachment 125603 [details] testcase boiled down to 18 pages /4MB Ehrenbuch-Interior-V7c_P-18.odt is same as previously suggested testcase ..P1-50.odt however content has been partially removed to reduce the size With this file the problem showed after most - not all - inital loads of the document. Steps to reproduce: 1. load the testcase file Ehrenbuch-Interior-V7c_P-18.odt # pagecount is showing initially 18 but after a short delay will still loading shows 19 # pagecount should be (Incorrect value) 19 2. use navigator to position on page 15 # you will be positioned on page 16 ! 3. Scroll back to see page 15 # You should find page number 15 in the footer but no paragraph-End on this page. The page is empty but the repro now on page 16 should be on this page. 4. Position the cursor after the last character on page 14 (after "gestiftet.") 5. Press enter (create new but empty paragraph on page 14 # the picture snaps back from page 16 to page 15, the total number of pages is reduced to 18 6. Press undo # the initial state is not restored, the empty paragraph on page 14 is removed, the total page count is 18, the document is flagged unmodified. 7. close the document (no save is suggested) 8. It should be possible to repeat above steps 1ff.
Reproducible with: Version: 5.4.0.0.alpha0+ Build ID: 9cfb2f2f03b5ec086487fd483298466db0b09010 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-12-20_23:58:02 Locale: nl-NL (nl_NL); Calc: CL
Created attachment 132352 [details] Example 3 (much easier, by jens116)
Comment on attachment 132352 [details] Example 3 (much easier, by jens116) I retested with Example 3 (Test5.odt) using Version: 5.3.7.2 (x64) Build-ID: 6b8ed514a9f8b44d37a1b96673cbbdd077e24059 CPU-Threads: 4; BS-Version: Windows 6.1; UI-Render: Standard; Layout-Engine: neu; Gebietsschema: de-DE (de_DE); Calc: group Behaviour is still faulty as decribed by jens116, the print preview shows the frame (after the change in width) at a new location - in my case on page 3 and so does the normal view. After storing and reopening the document shows Frame2 at the initial position and the document has 2 pages (=initial version).
I retested with Example 3 (Test5.odt) using Version: 6.1.3.2 (x64) Build-ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group threaded =========== Behaviour i still faulty ============ The document loads with (correct) 2 pages. However when I change the width of frame 1 the following frame 2 is pushed to the next side and the document has 3 pages. This can also be seen in a print preview. Pressing undo changes frame 1 to the initial size, however frame 2 does not return to page 2 but the document now is flagged unchanged!!! Following the test instruction found in frame 2 of the document Test5.odt I do not see a change in the normal view of the document after changing the frame width. However opening the print preview shows frame 3 shifted to page 3. Closing the print preview apparently updates the normal view which is now also showing frame 2 shifted to page 3 and marks the document changed!. I can save the changed document - I chose save to Test5x.ods. Reloading Test5x.ods shows a document with 2 pages. I was not able to reproduce the problem with the 18-pages example. The faulty behaviour with older versions was erratic and did not show up each time only some times. Today none of several tests with version 6.1 did load with a wrong page count.
Dear jens116, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug