Download it now!
Bug 118114 - Writer rotated text in table reorders itself instead of expanding cell (123456789 becomes 912345678)
Summary: Writer rotated text in table reorders itself instead of expanding cell (12345...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Vertical-Text
  Show dependency treegraph
 
Reported: 2018-06-11 14:35 UTC by Matt
Modified: 2020-01-09 17:32 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
A mostly-blank Writer doc with a table in it to reproduce the bug. (14.33 KB, application/octet-stream)
2018-06-11 14:37 UTC, Matt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matt 2018-06-11 14:35:47 UTC
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
Comment 1 Matt 2018-06-11 14:37:02 UTC
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.
Comment 2 Timur 2018-06-11 15:06:56 UTC Comment hidden (obsolete)
Comment 3 Timur 2018-06-11 15:11:35 UTC
I think it's 51930. See also 34436 and 91961

*** This bug has been marked as a duplicate of bug 51930 ***
Comment 4 Timur 2019-06-12 12:25:25 UTC
I repro with 6.4+ and set again to New.
Comment 5 Matt 2019-06-12 13:12:59 UTC
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.
Comment 6 Timur 2020-01-09 14:29:54 UTC
No repro 6.5+. WFM. Reerse bibisect would uncover the fix.
Comment 7 Matt 2020-01-09 17:32:09 UTC
Reproduced in 6.3.2.2 and 6.3.4.2.
The bug is fixed in 6.4.0.1. 
Thank you!!