Description: If we rotate a cell vertically, the top to bottom rotation wont work on some of the special characters, while the bottom to top seems to be working fine. See attached file. Steps to Reproduce: 1.Create a table 2.Write text in one of the cells, with a special character (like §) 3.Set the text orientation in the cells Table Properties -> Text Flow to Vertical (top to bottom) Actual Results: A rotated cell with rotated text, in which some of the special characters (like §) are not rotated. Expected Results: The special characters should be roteted as well, like in the vertical bottom to top rotation. 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
Created attachment 193191 [details] a table with rotated cells, which shows the bug
Confirm with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2887ffbf240aa70330cb50bf810170cf9c896405 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo Works in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) (but vertical bottom to top doesn't) - regression
Hmm, not sure we can call this "rotated cells", that remains open as bug 127485. Rather you've adjusted the 'Text orientation' for the respective cells. On left *btlr* with 'Vertical (bottom to top)' table orientation so just looks like left rotation, and on the right *tbrl* the 'Vertical (top to bottom)' table orientation so just looks like right rotation. OT fonts with actual vertical tables respond appropriately to the table orientation. However, there seems a legitimate difference with the handling of the symbol glyphs between btlr and tbrl orientation. And for OOXML interoperability Regina points out issues in see also bug 149556 @Miklos, you did the *btlr* dev that works correctly, was something to be done for the *tbrl* to get consistent results?
The main point was to go via SwRectFnSet whenever possible: once that's the case, that abstraction tries to do the right hing for the 4 writing directions Writer supports.
(In reply to Miklos Vajna from comment #4) > The main point was to go via SwRectFnSet whenever possible: once that's the > case, that abstraction tries to do the right hing for the 4 writing > directions Writer supports. So that was not the case for the "legacy" *tbrl* (Japanese/Chinese) orientation, reflected in this BZ issue? Sounds like a code pointer in there somewhere... And there are the OOXML text direction nomenclatures Regina noted in bug 149556
This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-5.3. Adding Cc: to Khaled Hosny ; Could you possibly take a look at this one? Thanks a96fae002641d2e60ade68bbd315ce0078f3d5a4 is the first bad commit commit a96fae002641d2e60ade68bbd315ce0078f3d5a4 Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Nov 10 02:01:17 2016 +0100 source f26df72f6e424492d101f527deb81f550ff3c941 source f26df72f6e424492d101f527deb81f550ff3c941 source 73b9b72cf1658208c2b2eb10cc0acfc3833dd875 https://git.libreoffice.org/core/+/f26df72f6e424492d101f527deb81f550ff3c941 https://git.libreoffice.org/core/+/73b9b72cf1658208c2b2eb10cc0acfc3833dd875 tdf#103718: Correctly set vertical direction
(In reply to raal from comment #6) > This seems to have begun at the below commit in bibisect repository/OS > bibisect-linux-64-5.3. > Adding Cc: to Khaled Hosny ; Could you possibly take a look at this one? > Thanks > a96fae002641d2e60ade68bbd315ce0078f3d5a4 is the first bad commit > commit a96fae002641d2e60ade68bbd315ce0078f3d5a4 > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Thu Nov 10 02:01:17 2016 +0100 > > source f26df72f6e424492d101f527deb81f550ff3c941 > > source f26df72f6e424492d101f527deb81f550ff3c941 > source 73b9b72cf1658208c2b2eb10cc0acfc3833dd875 > > https://git.libreoffice.org/core/+/f26df72f6e424492d101f527deb81f550ff3c941 > https://git.libreoffice.org/core/+/73b9b72cf1658208c2b2eb10cc0acfc3833dd875 > tdf#103718: Correctly set vertical direction There is no bug here. The expected output is wrong. This is not rotated text, but vertical text with embedded LTR text that gets rotated, “special” characters, CJK, etc, don’t get rotated for vertical text. The only bug here, as indicated in Comment 3, is that bottom to top text should behave like top to bottom text, but I don’t know why it doesn’t. Code in VCL checks for SalLayoutFlags::Vertical, so some code above it is not setting this flag.
(In reply to خالد حسني from comment #7) > The only bug here, as indicated in Comment 3, is that bottom to top text > should behave like top to bottom text, but I don’t know why it doesn’t. > > Code in VCL checks for SalLayoutFlags::Vertical, so some code above it is > not setting this flag. Bibisected with linux-64-7.0, this changed with a8d26a0bb40c101394ded8061d1b58048153631b commit a8d26a0bb40c101394ded8061d1b58048153631b Author: Miklos Vajna <vmiklos@collabora.com> Date: Mon Apr 6 21:02:30 2020 +0200 tdf#131490 sw btlr: fix handling of vertical text Miklós is already in Cc.
Thanks for the bisect! I believe the left cell gets rendered correctly and the right cell is bad currently. Before the above commit, the left cell was bad as well. So probably the fix will be around the same location. I agree that this is a bug and it's worth fixing, but I don't think this is a regression. Adjusting keywords accordingly.