Bug 34436 - TABLES text in cells behaves wrong when rotated (Shift Enter needed for line - see comment#3)
Summary: TABLES text in cells behaves wrong when rotated (Shift Enter needed for line ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: Not Assigned
: 41459 43618 69678 89850 (view as bug list)
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
Reported: 2011-02-18 03:47 UTC by sasha.libreoffice
Modified: 2020-03-01 00:53 UTC (History)
25 users (show)

See Also:
Crash report or crash signature:

Test case (12.88 KB, application/vnd.oasis.opendocument.text)
2011-11-08 02:13 UTC, Stefano Fraccaro
table with rotated text (13.01 KB, application/vnd.oasis.opendocument.text)
2014-06-28 07:02 UTC, rssdev10
Illustration of the position of the new paragraph. (27.19 KB, image/jpeg)
2020-02-18 14:10 UTC, Mark Hung
Test with cases (12.20 KB, application/vnd.oasis.opendocument.text)
2020-02-18 16:17 UTC, Timur
Test with cases for char and table rotate (13.31 KB, application/vnd.oasis.opendocument.text)
2020-02-18 17:01 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2011-02-18 03:47:54 UTC
I write in cell of table in Writer this text:
qwer asdf
Then I select it and change property of character:tab "Position" Rotation/scaling 90 degrees. Then I place cursor (caret) in middle of this text and press enter. Become:
Two parts of string swaps and produce no second line. In cell I can produce only one line of vertical text and never more.
It problem is from OpenOffice 2.0 until now.
Comment 1 sasha.libreoffice 2011-02-24 06:18:50 UTC
on Liberoffice 3.3.1 still exist
Comment 2 Vladimir Rutsky 2011-06-13 03:49:12 UTC
User vitriol explained that you should use <Shift+Enter> to separate lines in
vertically aligned paragraph (https://bugs.freedesktop.org/show_bug.cgi?id=38064#c1).
Comment 3 sasha.libreoffice 2011-06-13 23:21:08 UTC
With Shift-Enter it works.
My be need only add line "Use Shift-Enter for new line if text in table cell" to tooltip in Format->Character->tab Position->area Rotation/Scaling. It will solve this problem for many users.
Comment 4 Dmitry 2011-09-25 01:01:38 UTC
There is possibility to set the "Text direction" in "Table properties"("Text flow" tab). If you set "Right-to-left (vertical)" it work more correctly, intuitive and simply (for multiline just press Enter), than if you use  Format/Character/Position/Rotate. But the top of letters directed to the right. Therefore, I propose to add a item "Left-to-right (vertical)" to "Text direction" that would work similarly, but the top of the letters will look to the left. In my opinion this is the most correct and logical solution to rotate text for the table-cells.
Comment 5 Ramil 2011-09-25 02:03:12 UTC
Why when cursor is situated in start of string he became that:


Why when cursor in the end of string and I push Enter cursor stand that place:


But when I countinue print I saw that cursor is stand in start of first string:


Just try to work with vertical align of text and you understand that it is not obvious and asked...

P.S.: Would be cool if with LO we can make any degrees such as last picture (blue color).
Comment 6 Stefano Fraccaro 2011-11-08 02:13:14 UTC
Created attachment 53287 [details]
Test case
Comment 7 Stefano Fraccaro 2011-11-08 02:17:10 UTC
Video that show the problem with test case attachment:

Comment 8 Thomas Thym 2011-12-21 09:23:11 UTC
I can confirm that behaviour (also the wrong display mentioned by druido77@libero.it) in LO 3.5 beta1. It gave me quite a hard time here at the company until I found out that Ctrl+Enter is needed. 
Perhaps it is more intuitive to let "Enter" behave like "ctrl+Enter" when the orientation of the following paragraph is rotated, too.
Comment 9 Korrawit Pruegsanusak 2012-01-15 01:30:43 UTC
reset some values that come without appropriate reason, see http://wiki.documentfoundation.org/BugReport_Details
Comment 10 Stefano Fraccaro 2012-01-15 23:16:53 UTC Comment hidden (obsolete)
Comment 11 Stefano Fraccaro 2012-01-16 00:16:38 UTC Comment hidden (obsolete)
Comment 12 sasha.libreoffice 2012-01-16 04:10:20 UTC
Version - it is where bug first time found, and not current version.
Comment 13 Rainer Bielefeld Retired 2012-01-28 00:39:30 UTC
*** Bug 41459 has been marked as a duplicate of this bug. ***
Comment 14 Rainer Bielefeld Retired 2012-01-28 01:08:23 UTC
[Reproducible] with reporter's sample and "LibreOffice 3.5.0 RC2 German UI/Locale [Build-ID: e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium  (64bit). Also reproducible with own document.

Bug 41459 shows bug with a much more simple test case.

Related to "Bug 37828 - rotated text is not saved correctly in doc format"?

Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 15 dE 2012-04-20 02:15:16 UTC
I suggest the block 37361 should be removed cause this's not a frequently used feature and has a workaround.

Also I suggest downgrading it's priority.
Comment 16 Joel Madero 2013-02-07 19:52:04 UTC
Confirmed on Version (Build ID: 027bb41aa16793e88e9fc1b3550c8c893363647). 
Because LibreOffice 3.5 is now at end of life the 3.5 MAB is being closed. 

I agree with dE's input, while this might be quite annoying for some users, that list of users is very limited and therefore this bug should not be a MAB. 

MAB should affect a large portion of our user base OR be such a big bug that it would make professional quality work impossible. For this particular bug there is a workaround (although not ideal) which is to create the table in Spreadsheet and then copy/paste it to Writer - just tested this and it works.

Thanks for your understanding and apologies for the long delay.
Comment 17 retired 2013-09-18 10:19:04 UTC
Sasha, I just tried reproducing this problem in latest LO 4.2 master. But couldn't find the rotating option. Could you describe the exact steps how to reproduce?
Comment 18 sasha.libreoffice 2013-09-18 10:58:39 UTC
Select text, then menu Format->Character, then in dialog tab "Position" field "Rotation/Scaling" option "90 degrees" or "270 degrees".
Comment 19 tommy27 2013-10-11 05:48:02 UTC
*** Bug 69678 has been marked as a duplicate of this bug. ***
Comment 20 rssdev10 2014-06-28 07:02:42 UTC
Created attachment 101906 [details]
table with rotated text

See left column. It contains a paragraph with 2 strings only. But it is presented in LO with big distortions.
Comment 21 rssdev10 2014-06-28 07:03:44 UTC
The bug is still actual for LO beta2.
Comment 22 Timur 2015-01-28 18:29:32 UTC
*** Bug 43618 has been marked as a duplicate of this bug. ***
Comment 23 Timur 2015-01-28 18:46:22 UTC
I suggest this be renamed to "TABLE: rotated text in cells needs Ctrl+Enter to break properly"
Comment 24 QA Administrators 2016-02-21 08:37:49 UTC Comment hidden (obsolete)
Comment 25 Frank 2016-02-21 15:17:21 UTC
I'm using Ubuntu 14.04.3, with Writer Version:; Build ID: 1:5.0.5~rc2-0ubuntu1~trusty1.

This behavior still exists with my current setup.

I reported elsewhere that there is more to this quirk than meets the eye, however. If one attempts the same thing with any right-to-left script (e.g. Hebrew, Arabic, et al.) you'll find that the individual characters will be displayed in reverse order when rotated.

For example, if "ABCD" (pretend those are Hebrew characters for this example) is typed, the rotation and the behavior of [Enter] vs [Shift]+[Enter] will be as described in this bug, but will be displayed as "DCBA" - this occurs regardless of any CTL or language settings in use and, as near as I can tell, with any RTL script.

I'm not sure how relevant this is since, like most users who need to mix languages and scripts in the same document, I gave up on Writer some time ago and only use it for simple tasks.

But - for what it's worth - the quirks Sasha describes are still repeatable.
Comment 26 Andrei B. 2016-11-26 15:18:48 UTC
Fedora 25, LO
I was affected as well, as I was using Enter instead of Shift+Enter. Only after reading this issue I found out that "there is a way".
I would say though that the behavior of Enter is wrong and should be marked as a bug.
Note that in "Calc" I experienced no issues using text rotation in a cell.
Comment 27 Bruno MONDIN 2017-02-23 07:30:11 UTC
Windows 7 Pro : Libo 5.1x, 5.2x et 5.3x

I agree with the last comment of Andrei B.
The Shift Enter solution can not be judged as a satisfactory solution.
I think this is a long-standing bug that is still unresolved. It exists in 4.x, 5.1, it is always in 5.2 and finally in 5.3.
This also gives elements to our users to insist that MS Office is better.
Let's prove them wrong and fix this bug.
Comment 28 Timur 2017-07-07 08:43:22 UTC
*** Bug 89850 has been marked as a duplicate of this bug. ***
Comment 29 Roman Kuznetsov 2018-07-24 18:40:22 UTC
still repro in 

Version: (x64)
Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: ru-RU (ru_RU); Calc: CL
Comment 30 xavier.mathon 2019-01-23 16:15:10 UTC
Bug still present in Version: (x64)
Build ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5
Threads CPU : 4; OS : Windows 10.0; UI Render : par défaut; 
Locale : fr-FR (fr_FR); Calc: group
Comment 31 Helmut Leininger 2019-01-23 16:31:35 UTC
Still present in LO 
Version: (x64)
Build-ID: 2ce5217b30a543f7666022df50f0562f82be0cff
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-AT (de_AT); UI-Sprache: de-DE
Comment 32 Xisco Faulí 2019-12-02 13:11:47 UTC
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Comment 33 Mark Hung 2020-02-18 14:10:24 UTC
Created attachment 157978 [details]
Illustration of the position of the new paragraph.

I think this is not a bug although it is confusing. The new paragraph starts from the position where it ought to be as illustrated in the uploaded attachment. Consider where the position is if user set the rotation of the characters to 0 degree in the new paragraph. Remember the writing mode of the whole cell is still left-to-right (horizontal).

As Dmitry said in comment #4 that it is more logical a item "Left-to-right (vertical)" to "Text direction". A new writing mode Bottom-to-top(vertical) available since 6.4, which should also fit the use case.
Comment 34 Frank 2020-02-18 15:51:20 UTC
Re: "I think this is not a bug although it is confusing"

Seriously? If some feature is confusing to users, particularly those experienced enough to participate in the user forums, and is recognized as confusing by a developer, that is by any reasonable definition a BUG.

It's likely that the issue might not be one of coding inadequacies, but rather a lack of clear definition of what needs to happen during text entry or editing within a cell. As pointed out earlier, the specs for such a FUNDAMENTAL editing process should encompass all conditions, including the use of multiple script directions and so forth - just like normal use.

HINT: ask the question: why should the process/technique of editing text within a cell be any different [from a user's perspective] from editing in the document as a whole? If the answer is developer-centric (e.g. such behaviour is harder to code within a cell) rather than user-centric, this can be considered a CLUE.

Of course the excuse ("who uses that feature anyway?") can (as usual) be used to obfuscate the issue. If the feature is considered not to be useful, why not simply remove it? And I think we all know the answers (yes, plural) to that.
Comment 35 Timur 2020-02-18 16:17:06 UTC Comment hidden (me-too)
Comment 36 Timur 2020-02-18 17:01:00 UTC
Created attachment 157981 [details]
Test with cases for char and table rotate

Mark gave a fine explanation. In order to complete it, I also add test ODT with cases for char and table rotate. 
Technically and surprisingly, this is NotABug. 
Problem is maybe that LO has multiple ways of rotating text in table.
If done via chars, well, we must understand how it works. Or use table cell rotation.
For staying open, we need Expected results for both Enter and Shift+Enter. And reason why behavior for chars rotation should be changed, if exists possibility to rotate via table cell.
Comment 37 Heiko Tietze 2020-02-24 12:56:39 UTC
(In reply to Timur from comment #36)
> Technically and surprisingly, this is NotABug. 

I agree with NAB. And the issue is not related to tables, though it's more surprising since the style Table Content has zero distance between paragraphs. Just enter 123456, rotate, and add a break - it becomes 456 in the first paragraph followed by 123.
Comment 38 Timur 2020-02-25 09:02:55 UTC
I'll close this, as explained. 
While this *is* confusing, we have options:
- we need to check documentation and update it, if needed. 
- I opened bug 130807, to make options more obvious
- some rework of rotation, which could be another bug, but only if explained what's expected.
Comment 39 Frank 2020-02-25 14:24:18 UTC
Fascinating...  Yet another "Special Case" in Writer.

Why not carry this to its logical conclusion? When one rotates a page (rather than just a cell) from portrait to landscape mode, let's add a different set of behaviours for text handling. For example, as Keiko describes: "Just enter 123456, rotate, and add a break - it becomes 456 in the first paragraph followed by 123." This would at least make Writer's behaviour consistent.

As I asked in an earlier post, why should text entry and editing within a cell be any different at all [from a user perspective] from text entry and editing outside a cell?

The idea of altering the documentation to describe how "456 follows 123 but only in a cell" should prompt at least a bit of head-scratching (in logic, adding such documentation would be akin to what is called "reductio ad absurdum").

But, then again, if user confusion is the objective of the Writer team, has anyone considered the other possibilities: could cell editing be coded in such a way to have it respond differently depending on the direction of the rotation (clock-wise or counter-clockwise), e.g. have it produce 321 654 if the rotation is counter-clockwise? It would certainly be a shame to permit ANY opportunity to be more user-hostile pass by.

That isn't as silly or sarcastic as it sounds by the way. Writer still handles RTL (right-to-left, such as Arabic or Hebrew scripts) within rotated cells in a humorous (thought not quite achieving the status of encryption) fashion - swapping not only segments (e.g. the aforementioned 123 and 456) but individual characters as well. A Hebrew or Arabic segment does in fact act as if it is 321 654.

Editing in cells is BROKEN and has been for at least a decade and likely longer. It constitutes at least one BUG, and likely several. While editing or rotating text within a cell it MIGHT BE a special case from a programming standpoint, it should require no special knowledge or additional documentation.

Here's a quick stab at a full and complete explanation of what's expected: "". I'll repeat: "".

If that's unclear, it means a user should have no expectation that text entry or editing should be any different within a cell than it would be anywhere else.
Comment 40 Gerhard Schaber 2020-02-25 14:31:53 UTC
Or even put simpler--look at what MS Word does.
Comment 41 Timur 2020-02-26 09:54:18 UTC
(In reply to Frank from comment #39)
> Fascinating...  Yet another "Special Case" in Writer.
Whole comment is rather sarcastic than purposeful.
LO is volunteer based project. One can help by opening a bug that will (after searching, reading and pointing to similar bugs) explain what's exactly expected (starting from existing rotations) or help more by coding himself/herself. 
No point to further give general observations and complaints in a bug that's resolved at least by explaining the reason.

(In reply to Gerhard Schaber from comment #40)
> Or even put simpler--look at what MS Word does.
That's possible solution "some rework of rotation, which could be another bug, but only if explained what's expected" taking into account all possibilities.