Bug 92679 - Having some columns with vertical text orientation breaks right-to-left tables
Summary: Having some columns with vertical text orientation breaks right-to-left tables
Status: RESOLVED DUPLICATE of bug 114911
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: RTL-CTL Writer-Tables Vertical-Text
  Show dependency treegraph
 
Reported: 2015-07-10 20:14 UTC by Hapoofesgeli
Modified: 2018-01-30 18:09 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot showing the problem (14.23 KB, image/png)
2015-07-10 20:14 UTC, Hapoofesgeli
Details
Test case for bug 92679 (8.79 KB, application/vnd.oasis.opendocument.text)
2015-07-11 20:46 UTC, Hapoofesgeli
Details
Attempt to reproduce the bug in 6.0.0 (8.52 KB, application/vnd.oasis.opendocument.text)
2017-11-09 07:33 UTC, Omer Zak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hapoofesgeli 2015-07-10 20:14:18 UTC
Created attachment 117177 [details]
Screenshot showing the problem

Steps to reproduce:
*Add a table with right-to-left text direction
*select a column and make its text orientation vertical
*Copy/paste the table somewhere or reopen the file

You'll see that the table jumps to the left side and nothing seems to fix it except changing the table's text direction to left-to-right which basically mirrors the table.
Comment 1 Joel Madero 2015-07-11 20:39:07 UTC
Please attach a document that shows the issue. While screenshots are helpful, original documents help a lot more.

Also setting to:
Normal - prevents high quality work;

Major is reserved for loss of data, crashes, and the like. This does not qualify.

Also, a couple other questions:
1) Is there a workaround (can you do *anything* to make it work)?
2) Is this a new issue? Would be great if you could test in 3.3
http://downloadarchive.documentfoundation.org/libreoffice/old/


Setting to NEEDINFO to at least get the attachment. Set to UNCONFIRMED once you attach (and ideally answer the other questions) Thanks!
Comment 2 Hapoofesgeli 2015-07-11 20:46:32 UTC
Created attachment 117184 [details]
Test case for bug 92679
Comment 3 Joel Madero 2015-07-11 20:53:40 UTC
In the future please set the bug to UNCONFIRMED after you do whatever the comment requests of you. Else, QA never looks at the bug again and it's closed as INVALID after 7 months. Thanks
Comment 4 Joel Madero 2015-07-11 20:59:48 UTC
Confirmed:
Ubuntu 15.04
LibreOffice 3.3 (inherited from OOo)

Setting to:
NEW;
Normal - can prevent high quality work, from what I can see there is no workaround;
Medium - default
Comment 5 Hapoofesgeli 2015-07-11 21:05:58 UTC
Thanks for testing it out in 3.3, there are no builds for my distribution so it would be a hard job to test it.

And as for a workaround there seems to be none and to get the table back to a normal state you should either change the the table text direction to left-to-right or set back the text orientation of all cells to horizontal.
Comment 6 QA Administrators 2016-09-20 10:13:58 UTC Comment hidden (obsolete)
Comment 7 Omer Zak 2017-11-09 07:32:24 UTC
I tested in version:

Version: 6.0.0.0.alpha1+
Build ID: 6070dec9ca9a15587a2aece81f9ae1ab5ac0f8c4
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.utf8); Calc: group
(Build from 2017-Nov-05 00:00)

OS: Debian 64bit Stretch (Debian 9.2, with some backported packages)


I created a table with Hebrew in cells.
I changed the text orientation to vertical after selecting all cells in the table and using:

  Format > Character > Position > Rotation/Scaling > 90 degrees

The table remained right justified after reopening the file. However, the column widths changed.
Comment 8 Omer Zak 2017-11-09 07:33:29 UTC
Created attachment 137629 [details]
Attempt to reproduce the bug in 6.0.0
Comment 9 Buovjaga 2018-01-30 18:09:35 UTC
Duping this to a newer one because it has clearer steps.

*** This bug has been marked as a duplicate of bug 114911 ***