When entering text in a table with a long vertical column, selecting Character/Position (tab), Rotation/Scaling (I've only tested 90 degrees), saving the document and reloading results in the vertical text being garbled. For example 'Sunday' rotated counter clockwise 90 degrees with the S on the bottom and y on the top, looks fine. Saving as an .odt document and reloading results in (bottom to top): ydanuS, with 'S' as a subscript. Sometimes the characters are more scrambled than reverse order. This seems to be font specific. The default Liberation Serif doesn't do it, but Times New Roman will.
I withdraw the comment about font. My old document was TNR, tried to duplicate in a new document with default font and couldn't. Changed the font from Liberation Serif to Times and the bug appeared. Changing the font in the original document from Times to Liberation did not make the problem go away. A font change may need to be made to reproduce this, but specific fonts do not seem immune.
I tried to duplicate but couldnt. Can you send in an example file that you create and when you create it save it also as a .odt, .docx, .doc, and .rtf, as well as exporting it as a pdf before you close the document, and send all these other files as well.
Created attachment 100214 [details] Sample Document
Created attachment 100215 [details] Sample Document .DOCX doesn't seem to be effected.
Created attachment 100216 [details] Sample Document
Created attachment 100217 [details] Sample Document
Cannot attach .PDF format. Any suggestions for that?
Testing with all these formats, it appears to be that the saved files are okay (loading in MS Word shows that), but loading them in Writer is when the scrambling occurs. (DOCX isn't effected). Again adding or deleting a character or changing the cell size immediately causes the text to self correct. Since it isn't clear, I am using Windows 7 SP1 x64.
You can possibly save it in dropbox, google drive, onedrive, ge.tt, or other free online storage website and then provide us with the link.
I didn't know if adding the attachment here was preferable or possible. PDF version: http://www.mediafire.com/view/71mlbr3fplf73xk/Vertical_Text.pdf Still, the documents appear to be okay as written and the problem seems to occur when importing them into Writer.
Confirmed in Linux Mint and Windows 7. The words of characters in each works are correct, but the words are in reverse order. If you add a character to the jumped works, then it will appear in correct order. I wasnt able to create a file like this, but testing the reporters attached files, confirmed it.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.3 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-06-08
Still a problem. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
That version trumps me, I'm on v4.4.3.2. Win7 x64. And yeah, I still see this bug as well.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Tested with v5.2.1.2 on Win7 X64. Bug is still present. Doesn't seem like anyone has attempted to fix it.
Looks like a duplicate. You'll be in CC there and get eventual updates. *** This bug has been marked as a duplicate of bug 51930 ***
Please see also well-known Bug 34436.
Steps: Open attachment 100216 [details] See that text in first column "A Sample Line of Text" is shown incorrectly. Type space anywhere in that merged cell and it will look OK. Save, close and reopen. See the same issue. So not fixed. Repro OO and 6.4+. Note: not an issue with Pair kerning, specific font or Microsoft fonts.
Another possible example attachment 119095 [details] reported in Bug 51930.
This bug does indeed still exists. LibreOffice v6.2.4.2 x64 on Win7
One of those happy moments when you retest and find out that some mysterious dev has resolved this, maybe without even intending it. per Comment 19 for attachment 100216 [details] and attachment 119095 [details] repro LO 6.3.3 and no repro in 6.5+.