Bug 114911 - Setting vertical orientation for first cell in table row shifts rendering of row on save & reopen
Summary: Setting vertical orientation for first cell in table row shifts rendering of ...
Status: NEW
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:
: 92679 (view as bug list)
Depends on:
Blocks: Writer-Tables 114883 RTL-Rotation
  Show dependency treegraph
 
Reported: 2018-01-08 14:45 UTC by Eyal Rozenberg
Modified: 2024-08-17 08:28 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Document manifesting the bug (8.29 KB, application/vnd.oasis.opendocument.text)
2018-01-08 14:45 UTC, Eyal Rozenberg
Details
"Before" screenshot (after step 4) (5.37 KB, image/png)
2018-01-08 14:46 UTC, Eyal Rozenberg
Details
"After" screenshot (after step 6) (5.95 KB, image/png)
2018-01-08 14:47 UTC, Eyal Rozenberg
Details
"Before" screenshot (after step 4) (3.16 KB, image/png)
2018-01-30 18:17 UTC, Eyal Rozenberg
Details
"After" screenshot (after step 6) (3.25 KB, image/png)
2018-01-30 18:18 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2018-01-08 14:45:13 UTC
Created attachment 138969 [details]
Document manifesting the bug

Perform the following:

1. Set default style direction to RTL
2. Created a 1x2 table (1 row, 2 columns
3. Enter text in each cell: A, B
4. Set the first cell (should be rightmost cell in RTL order) to have vertical flow (e.g. via the menus: Table | Properties | Text Flow | Text orientation)
5. Save & close the file
6. Open the file you just saved

Result: The entire line's rendering gets shifted to the left. You can see this by comparing the "before closing" and "after reopening" screenshot.

This _seems_ to be a problem with the way LO loads saved data, as the problem does not occur with this layout before the file is closed and reopened. It is probably not a problem with the saving code, since we're also seeing this issue (and another one) in the blocked bug 114883 - where the file was saved in Microsoft Word (and opens correctly with Word).

Notes:

* The bug manifests per-line, so if you make the table 2x2, and only change the layout to vertical on the second line, you'll only get a shift on the second line.
* If the line has just one cell (which gets oriented vertically), the bug doesn't manifest.
* You can't see the attached ODT _without_ the bug - you have to create a new document for that.

Thanks go to Mike Kaganski for "extract"ing this simplified issue out.
Comment 1 Eyal Rozenberg 2018-01-08 14:46:48 UTC
Created attachment 138970 [details]
"Before" screenshot (after step 4)

Screenshot of how the table _should_ be laid out, and _is_ laid out before we close the document file.
Comment 2 Eyal Rozenberg 2018-01-08 14:47:42 UTC
Created attachment 138971 [details]
"After" screenshot (after step 6)

Screenshot with the bug manifesting - after saving, closing and opening the document which exhibited the "before" shot.
Comment 3 Buovjaga 2018-01-30 18:02:21 UTC
Repro from scratch.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: 73c757ff71b6bf14206adf13a65213c79928a592
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on January 30th 2018

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 4 Buovjaga 2018-01-30 18:09:35 UTC
*** Bug 92679 has been marked as a duplicate of this bug. ***
Comment 5 Eyal Rozenberg 2018-01-30 18:17:42 UTC
Created attachment 139450 [details]
"Before" screenshot (after step 4)

Previous version of screenshot used a 2x2 table (while the reproduction instructions only need a 1x2 table).
Comment 6 Eyal Rozenberg 2018-01-30 18:18:04 UTC
Created attachment 139451 [details]
"After" screenshot (after step 6)

Previous version of screenshot used a 2x2 table (while the reproduction instructions only need a 1x2 table).
Comment 7 Eyal Rozenberg 2018-09-17 19:28:08 UTC
Bug still manifests with:

Version: 6.1.1.2
Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; 
Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Comment 8 QA Administrators 2019-09-18 02:53:29 UTC Comment hidden (obsolete)
Comment 9 Eyal Rozenberg 2019-09-18 22:34:09 UTC
Bug still manifests as described with:

Version: 6.3.1.2
Build ID: 1:6.3.1-1
CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; 
Locale: he-IL (en_IL); UI-Language: en-US
Calc: threaded
Comment 10 QA Administrators 2021-09-18 03:26:21 UTC Comment hidden (obsolete)
Comment 11 Eyal Rozenberg 2021-09-18 07:17:13 UTC
Bug still manifests with:

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_IL); UI: en-US
Calc: CL

Additional notes on the reproduction instructions:

* It doesn't matter if the paragraph alignment is Left, Right or Justified.
* When you set the vertical alignment, you don't have to first make sure and select exactly the single cell; it's enough if you just have your cursor in that cell, for it to be the only one effected.
Comment 12 QA Administrators 2021-09-19 03:43:24 UTC Comment hidden (obsolete)
Comment 13 Eyal Rozenberg 2021-10-15 21:33:05 UTC
Bug still manifests with:

Version: 7.2.0.1 / LibreOffice Community
Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc
CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_IL); UI: en-US
Comment 14 Stéphane Guillou (stragu) 2023-12-15 22:15:08 UTC
Reproduced from scratch in:

Version: 24.2.0.0.beta1 (X86_64) / LibreOffice Community
Build ID: 5f390384195b7264c6e52add9e90a39790285249
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded