Description: There seem to be two layout algorithms used when displaying a text box. One is used when originally opening the slide and one after any editing (even NULL editing) has taken place. They result in different layouts and therefore confusion to the user about the object placements. This did not happen in 6.1.2.1 (or actually, when opening the slide, it first quickly displayed it in the pre-editing layout but then immediately performs a redraw in post-editing layout. These two drawing events can be seen when opening the slide.) Steps to Reproduce: 1. Open lobug.odt. The slide is shown in pre-editing layout (see also screenshot BeforeEditing.png) 2. Click in the text area. The layout stays the same (see also screenshot WhileEditing.png; cursor is not visible here) 3. Click outside the text area. The layout changes drastically (see also screenshot AfterEditing.png; now the callouts are "correctly" placed) Actual Results: The text is drawn differently depending on whether the text has been in edit mode at least once. The problem is that the post-editing layout is not identical to the presentation layout (the pre-editing layout is). Expected Results: The layout before, while, and after editing is identical to the layout used for presentation. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info:
Created attachment 147280 [details] Presentation that displays the bug
Created attachment 147281 [details] Screenshot that displays the layout before starting to edit
Created attachment 147282 [details] Screenshot that displays the layout before while in edit mode (no edits being done here)
Created attachment 147283 [details] Screenshot that displays the layout after exiting edit mode (no edit has taken place)
Thank you for reporting the bug. I can confirm that the bug is present in Version: 6.1.3.2 Build ID: 86daf60bf00efa86ad547e59e09d6bb77c699acb CPU threads: 2; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group threaded
looks similar to bug 121861. Closing as RESOLVED DUPLICATED *** This bug has been marked as a duplicate of bug 121861 ***