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: asdfqwer 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.
on Liberoffice 3.3.1 still exist
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).
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.
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.
Why when cursor is situated in start of string he became that: [url=http://itmages.ru/image/view/289061/5d2603bf][img]http://storage1.static.itmages.ru/i/11/0925/s_1316941191_4035998_5d2603bf71.png[/img][/url] Why when cursor in the end of string and I push Enter cursor stand that place: [url=http://itmages.ru/image/view/289059/41fccf43][img]http://storage8.static.itmages.ru/i/11/0925/s_1316941168_3799594_41fccf438d.png[/img][/url] But when I countinue print I saw that cursor is stand in start of first string: [url=http://itmages.ru/image/view/289058/001e3a6f][img]http://storage7.static.itmages.ru/i/11/0925/s_1316941112_3483110_001e3a6fe4.png[/img][/url] 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).
Created attachment 53287 [details] Test case
Video that show the problem with test case attachment: http://monteldvd.sf.net/bug/text_rotated.avi
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.
reset some values that come without appropriate reason, see http://wiki.documentfoundation.org/BugReport_Details
I don't understand why you have changed from 3.4.4 back to 3.3.0 . I change newly to 3.4.4 because I have this problem on LibO 3.4.4 on Windows XP LibreOffice 3.4.4 OOO340m1 (Build:402) (In reply to comment #9) > reset some values that come without appropriate reason, see > http://wiki.documentfoundation.org/BugReport_Details
Same problem on LOdev 3.5.0beta2 Windows XP Build ID: 8589e48-760cc4d-f39cf3d-1b2857e-60db978
@druido77@libero.it Version - it is where bug first time found, and not current version.
*** Bug 41459 has been marked as a duplicate of this bug. ***
[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"? @Cédric: 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.
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.
Confirmed on Version 4.1.0.0.alpha0+ (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.
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?
Select text, then menu Format->Character, then in dialog tab "Position" field "Rotation/Scaling" option "90 degrees" or "270 degrees".
*** Bug 69678 has been marked as a duplicate of this bug. ***
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 4.3.0.0b2 with big distortions.
The bug is still actual for LO 4.3.0.0 beta2.
*** Bug 43618 has been marked as a duplicate of this bug. ***
I suggest this be renamed to "TABLE: rotated text in cells needs Ctrl+Enter to break properly"
** 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.0.5 or 5.1.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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
I'm using Ubuntu 14.04.3, with Writer Version: 5.0.5.2; 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.
Fedora 25, LO 5.2.3.3 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.
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. Thanks Regards
*** Bug 89850 has been marked as a duplicate of this bug. ***
still repro in Version: 6.1.0.2 (x64) Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ru-RU (ru_RU); Calc: CL
Bug still present in Version: 6.0.7.3 (x64) Build ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5 Threads CPU : 4; OS : Windows 10.0; UI Render : par défaut; Locale : fr-FR (fr_FR); Calc: group
Still present in LO Version: 6.2.0.2 (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
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
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.
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.
Created attachment 157980 [details] Test with cases Fine explanation. I also add test ODT with cases. Technically and surprisingly, this is NotABug. For staying open, we need Expected results for both Enter and Shift+Enter.
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.
(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.
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.
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.
Or even put simpler--look at what MS Word does.
(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.