Description: Typing in a table cell with text rotated 270 degrees sometimes results in letters or words being put in the wrong order in the cell. Sometimes it appears right on the Writer screen and sometimes wrong. I noticed the problem at first when I exported to PDF a document I was working on. I constructed the test case (which I will attach) that is much simpler than my real-life document. Steps to Reproduce: 1. click on first cell of table in attached document 2. type 123456789 Actual Results: When you type the '9', notice how it moves to the front of the text, before the '1'. Expected Results: The '9' should stay where I want it, at the end of the text. Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 8; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Created attachment 142659 [details] A mostly-blank Writer doc with a table in it to reproduce the bug. Type 12345689 into the first cell and watch what happens.
duplicate
I think it's 51930. See also 34436 and 91961 *** This bug has been marked as a duplicate of bug 51930 ***
I repro with 6.4+ and set again to New.
Reproduced on Version: 6.2.3.2 (x64) Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Reproduced on Version: 6.2.4.2 (x64) Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Clues 1. After typing 123456789, select all, copy, go to a text editor and paste. The text comes out in the right order. 2. Tighten up the height of the row. Then typing 123456 will expose the bug. I can even make the row short enough that 123 exposes the bug. Seems to have to do with wrapping of text in the cell, like the wrapping is initially not moving "down" to the next line, or, since the text is rotated, not moving "over" to the next line. 3. Finally, I apologize because I realize now that the paragraph style in the test.odt is rotated 90 degrees, NOT 270. If I right click and set Paragraph | Edit Style to have a 270 degree rotation, then 123... works as expected. Typing 123456789 automatically expands the height of the row to accommodate the text and the characters remain in the correct order. 4. Back to 90-degree "bug mode," type 123456789, and observe how the character that mysteriously popped to the front of the text will pop back into proper place if you type another character. That new character is in the wrong location. Type another, and it will pop back to its proper place, and the new one will be wrong.
No repro 6.5+. WFM. Reerse bibisect would uncover the fix.
Reproduced in 6.3.2.2 and 6.3.4.2. The bug is fixed in 6.4.0.1. Thank you!!
Rebisect 7.0 commit c07ff5ae3654a0181ac65f1c340e621478da606f Date: Thu Dec 5 00:30:09 2019 +0100 source 0fa95852b0968fa2a35efb8ca816949c58af56e0 previous source 281f3d5c418e50a2858619633ebca290bd626c03 author Miklos Vajna <vmiklos@collabora.com> 2019-12-04 17:55:22 +0100 committer Miklos Vajna <vmiklos@collabora.com> 2019-12-04 20:21:54 +0100 commit 0fa95852b0968fa2a35efb8ca816949c58af56e0 (patch) tree a63f44e6133f147c15a43c85c49b5bbad57da6e1 parent 281f3d5c418e50a2858619633ebca290bd626c03 (diff) tdf#128611 sw: improve rotated text layout in table cells *** This bug has been marked as a duplicate of bug 128611 ***