Created attachment 113918 [details] DOCX with table generated by MSO Word DOCX generated by MS Word 2010. - The first Column has vertical text. - The first cell of the first row has some line breaks. - The first cell of the second row does not have line breaks. If we create a simple table in MSO and set some cells to vertical text, when editing the document in LibreOffice the behavior is quite strange: - If you press Enter at the end of the cell (the one with vertical text), the text does not jump to the next line, it moves to the beginning of the text or a position that is not correct. - With a vertical text cell selected, go to table properties: the text orientation is set to horizontal, yet the text displays vertically. If you change the orientation to vertical, the orientation changes to horizontal. In this condition, alignment and vertical alignment also behaves strangely. Example DOCX attached. Environment: LibreOffice 4.4.0.3 OS: Windows 7 64bit (Spanish)
Created attachment 113919 [details] PDF with expected results
Please attach a pdf of what you see with LibreOffice and also include your exact operating system and version of LibreOffice. Marking as NEEDINFO - once you provide this info please set to UNCONFIRMED. Thanks
Created attachment 113928 [details] PDF with wrong results
Hi Joel, Exact versions are already on the first text: Environment: LibreOffice 4.4.0.3 OS: Windows 7 64bit (Spanish) PDF with wrong LibreOffice results attached Thanks
OS: Windows 7 Professional + SP1, 64bit, Spanish
On Linux, "Row 2 test header" is wrapping correctly. Otherwise reproduced. I wonder, if this is related to bug 75456 somehow. Not sure enough to close as dupe (text box vs. table cell). Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI Version: 4.5.0.0.alpha0+ Build ID: 181feb38d95e25980b96c2f6802cc906410abb13 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-19_23:38:28 Locale: fi_FI Ubuntu 14.10 64-bit Version: 4.4.1.2 Build ID: 40m0(Build:2) Locale: en_US Version 3.6.7.2 (Build ID: e183d5b)
Created attachment 120073 [details] MS Word 2010 screenshot (Original document)
Created attachment 120074 [details] LO5 Writer screenshot
Created attachment 120075 [details] Document with vertical text at the bottom left corner.
Do I have the same bug? I attached 3 screenshots where the text gets scrambled in LO Writer 4/5. Tried doc, docx, dot, dotx. Tried saving in writer as ODT, OTT. You can temporarily fix it by Character->text orientation 0 deg.->OK. ->text orientation->90 deg. After reloading its wrong again as in the Writer screenshot.
(In reply to Sven Ollino from comment #10) > Do I have the same bug? Sure looks like it. If you want to help with our bug situation, but don't know C++: https://wiki.documentfoundation.org/QA/Triage_For_Beginners
Tested on LibreOffice 3.3.0.4, OOO330m19 (Build:6) OS: Windows XP SP3 The issue happens in LO first release.
No change was done between OOo and 3.3 so this was inherited.
** 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.2.5 or 5.3.0 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-20170306
Bug still present on: LibreOffice 5.3.0.3 Build: 7074905676c47b82bbcfbea1aeefc84afe1c50e1 Locale: ca_ES OS: Windows 10 Pro 64bit Spanish, 1607 version, 14393.693 compilation.
(In reply to Consorci Sanitari de l'Alt Penedès from comment #0) > - If you press Enter at the end of the cell (the one with vertical text), > the text does not jump to the next line, it moves to the beginning of the > text or a position that is not correct. That should be Bug 34436. Also suffers from Bug 51930, Bug 38066. > - With a vertical text cell selected, go to table properties: the text > orientation is set to horizontal, yet the text displays vertically. If you > change the orientation to vertical, the orientation changes to horizontal. > In this condition, alignment and vertical alignment also behaves strangely. This text is rotated via Format-Character-Position, not by table properties. There are 3 ways to rotate, also by edit style. See Bug 88895, Bug 108993, Bug 91961. Rules of thumb: first search for existing bugs, then report each issue separately. I'll mark this one as a duplicate. Please feel free to disagree if you find that other bugs don't cover those issues. *** This bug has been marked as a duplicate of bug 34436 ***