While there are options to rotate text by 90 and 270 degrees. There is no option to rotate by 180 degrees.
People need to design cards and brochures with horizontal folds all the time. These documents will have at least one side which is inverted (180 degrees). This should be easy for the user to do.
If someone already figured out how to get 90 and 270 to work, how much harder could 180 be?
All sorts of software routinely gets things upside down backwards by accident. How hard could it be to do it on purpose?
I know there is a workaround - inserting an ole drawing object with the text rotated, but this is way less than obvious or simple and took me quite awhile to figure out.
I'll try to tackle this one. Thanks for the suggestion
Thanks for taking a look at this. Any progress on it?
None but I have a friend who I hope is going to help me out. The code isn't nearly as straight forward as you'd think/hope.
When we implement a change I hope to allow any rotation not just the three (90, 180, 270), so we need to dig deeper into the code.
After 4.0 releases and QA work has calmed down a bit, I'll dedicate a bit more time to this and hopefully figure something out.
Sorry for the delay, only so many hours in a day :)
That sounds pretty ambitious! All I want to do is print upside down on a
folded greeting card. Thanks for the reply.
On Tue, Jan 15, 2013 at 11:48 AM, <firstname.lastname@example.org> wrote:
> Joel Madero <email@example.com> changed bug 48804<https://bugs.freedesktop.org/show_bug.cgi?id=48804>
> What Removed Added CC firstname.lastname@example.org
> *Comment # 3 <https://bugs.freedesktop.org/show_bug.cgi?id=48804#c3> on bug
> 48804 <https://bugs.freedesktop.org/show_bug.cgi?id=48804> from Joel
> Madero <email@example.com> *
> None but I have a friend who I hope is going to help me out. The code isn't
> nearly as straight forward as you'd think/hope.
> When we implement a change I hope to allow any rotation not just the three (90,
> 180, 270), so we need to dig deeper into the code.
> After 4.0 releases and QA work has calmed down a bit, I'll dedicate a bit more
> time to this and hopefully figure something out.
> Sorry for the delay, only so many hours in a day :)
> You are receiving this mail because:
> - You reported the bug.
This isn't quite a simple "+1", although it is that too.
Ideally, the four compass points should have a radio button (0, 90, 180, 270 degrees): that's the real need. "Infinite" rotation (user definable) would be lovely some day, but not nearly so important.
*Also* note that used in tables, the rotated text should still respect cell boundaries. At the moment, if you rotate text 90 or 270, then a "paragraph" will become a single line, as neither soft line-breaks, nor hard paragraph-breaks are respected. (Should this be filed as a separate bug?)
Very much looking forward to this enhancement/bug-fix coming through!
Unfortunately I just haven't had the time to solve this bug - if I make any progress I will report back but until then setting back to default and NEW
Just want to add a +1, especially to all the points in comment 5. It would be great great great to get that 180 radio button. Thanks!
I am unassigning myself from this - despite what might be seen as an easy hack - it's a very very hard hack that is well beyond my skills. I had another developer friend of mine look and she even said it was pretty tough (she's been in the industry for 5 years) - so as a hobbiest, just beyond my skillset.
This is another +1 for this much needed feature. For now I used a drawing text block and rotated the frame 180, which worked, but was far more complicated for my needs.
There is a standard that prescribes that title page of a document must have a table, in which text goes vertically. AND THANKS TO THE WONDERFUL LIBREOFFICE I can do only the reverse of that. These jokes about ‘In Soviet Russia…’ went too far. Where’s my rotation on 180°?
Please don't manipulate the severity/priority to try to influence your pet bugs. It was appropriately set before, reverting the change.
The standard ODF allows transformations on a <draw:frame> element, but LibreOffice allows it only for those <draw:frame> elements, which are made by the T symbol (a shape in the view of LibreOffice) and not for those, which are made by Insert > Frame. With implementing this feature, such requests could be solved by putting the content into a frame.
*** Bug 90294 has been marked as a duplicate of this bug. ***
Note: when mail merging, you cannot put a field inside a textbox. So, there is no way to rotate it 180 degrees.
Would this really be so difficult to implement that it's an open issue since 2004 (see https://bz.apache.org/ooo/show_bug.cgi?id=29150)?
Maybe this is not a day-to-day issue, but it makes things like folder-back templating really tricky. My +1 for this bug!