Bug 160273 - Writing direction with rotated text in cell is inconsistent
Summary: Writing direction with rotated text in cell is inconsistent
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.6.5.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Vertical-Text
  Show dependency treegraph
 
Reported: 2024-03-19 09:43 UTC by Csábi Frigyes
Modified: 2024-04-09 03:13 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
A table with rotated cells, showing the inconsistency (19.02 KB, application/vnd.oasis.opendocument.text)
2024-03-19 09:45 UTC, Csábi Frigyes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Csábi Frigyes 2024-03-19 09:43:53 UTC
Description:
The writing direction with multiline content is the same with the left cell rotation (vertical bottom to top) and the left text rotation (90°), which is left to right, the new line breaks under the old one, but as we can see in the attached file, it differs with the left cell (vertical top to bottom) and left text (270°) rotation.
The left text rotation (270°) should work similarly to the left cell rotation (vertical top to bottom), as in the writing direction should be right to left.

Steps to Reproduce:
1.Create table
2.Write text in a cell
3.Rotate the text in the cell: Character -> Position -> Rotation/Scaling 270 degrees
4.Break the text in the cell (Shift + Enter on Windows)

Actual Results:
The text breaks in a left to right direction, the new line is "on top" of the old one

Expected Results:
The new lines should break "under" the old one, and follow a right to left direction, like with the right cell rotation (vertical top to bottom)


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 7.6.5.2 (X86_64) / LibreOffice Community
Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: threaded
Comment 1 Csábi Frigyes 2024-03-19 09:45:11 UTC
Created attachment 193192 [details]
A table with rotated cells, showing the inconsistency
Comment 2 V Stuart Foote 2024-03-19 14:53:39 UTC
You are mixing Table/Table Cell *text orientation* up with Character *text rotation*.

Different attributes!

Table layout BTLR is different to TBRL -- the 90 left rotation happens to match the layout of the BTLR orientation.  Simply put, the 270 right rotation does not match layout of TBRL orientation.

IMHO => NAB
Comment 3 Csábi Frigyes 2024-03-19 19:01:44 UTC
(In reply to V Stuart Foote from comment #2)
> You are mixing Table/Table Cell *text orientation* up with Character *text
> rotation*.
> 
> Different attributes!
> 
> Table layout BTLR is different to TBRL -- the 90 left rotation happens to
> match the layout of the BTLR orientation.  Simply put, the 270 right
> rotation does not match layout of TBRL orientation.
> 
> IMHO => NAB

Hmm, yes you are right, the 270 rotation is still left to right. My problem is, that it is very hard to read. And if i try to change it to right to left (Ctrl + Shift + D in Windows) it messes up the text. Would you consider this as a bug?
Comment 4 Stéphane Guillou (stragu) 2024-04-05 01:26:26 UTC
(In reply to V Stuart Foote from comment #2)
> You are mixing Table/Table Cell *text orientation* up with Character *text
> rotation*.
> 
> Different attributes!
> 
> Table layout BTLR is different to TBRL -- the 90 left rotation happens to
> match the layout of the BTLR orientation.  Simply put, the 270 right
> rotation does not match layout of TBRL orientation.
> 
> IMHO => NAB
I agree with Stuart here. Character rotation is a character effect, not a whole-paragraph or whole-cell tool.

(In reply to Csábi Frigyes from comment #3)
> Hmm, yes you are right, the 270 rotation is still left to right. My problem
> is, that it is very hard to read. And if i try to change it to right to left
> (Ctrl + Shift + D in Windows) it messes up the text. Would you consider this
> as a bug?
Why would you change an LTR script to RTL direction? In this case, the character rotation and the writing direction features would be both missused. If you want the text contained in a table cell to be read by tilting your head to the right, cell rotation has to be used. What is wrong with using cell rotation?
Comment 5 Csábi Frigyes 2024-04-09 00:44:43 UTC
(In reply to Stéphane Guillou (stragu) from comment #4)
> (In reply to V Stuart Foote from comment #2)
> > You are mixing Table/Table Cell *text orientation* up with Character *text
> > rotation*.
> > 
> > Different attributes!
> > 
> > Table layout BTLR is different to TBRL -- the 90 left rotation happens to
> > match the layout of the BTLR orientation.  Simply put, the 270 right
> > rotation does not match layout of TBRL orientation.
> > 
> > IMHO => NAB
> I agree with Stuart here. Character rotation is a character effect, not a
> whole-paragraph or whole-cell tool.
> 
> (In reply to Csábi Frigyes from comment #3)
> > Hmm, yes you are right, the 270 rotation is still left to right. My problem
> > is, that it is very hard to read. And if i try to change it to right to left
> > (Ctrl + Shift + D in Windows) it messes up the text. Would you consider this
> > as a bug?
> Why would you change an LTR script to RTL direction? In this case, the
> character rotation and the writing direction features would be both
> missused. If you want the text contained in a table cell to be read by
> tilting your head to the right, cell rotation has to be used. What is wrong
> with using cell rotation?

Yes, using cell rotation would be the more convenient, but it raises a problem mentioned in Bug 160271, which seems to be considered NAB. Not to mention another issue. We have to work with merged AND rotated cells, and they dont break "well" when they continue on multiple pages, leaving sometimes half of the page empty (Even with allowing row breaking). Rotating the text instead of the cell fixes this as well.
Comment 6 QA Administrators 2024-04-09 03:13:32 UTC Comment hidden (obsolete)