Bug 143377 - FORMATTING and PRINTING: Setting Border with rotated text changes row background color (not with gen VCL backend)
Summary: FORMATTING and PRINTING: Setting Border with rotated text changes row backgro...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: x86 (IA32) All
: medium normal
Assignee: Armin Le Grand
URL:
Whiteboard: target:7.5.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Vertical-Text
  Show dependency treegraph
 
Reported: 2021-07-15 03:11 UTC by BugzillaReporter
Modified: 2022-11-01 11:31 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenprint with poorly painted sheet (165.19 KB, image/png)
2021-07-15 03:20 UTC, BugzillaReporter
Details
An .ods file with copy of sheet used to create screenshot (18.31 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-07-15 03:23 UTC, BugzillaReporter
Details
An image of the printed Pages (3.59 MB, image/jpeg)
2021-07-15 03:35 UTC, BugzillaReporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description BugzillaReporter 2021-07-15 03:11:26 UTC
Description:
I just upgraded Linux Mint.  This spreadsheet opened and printed successfully in March, 2021.

This Calc has a tab to print a weight tracking form. It has 30 rows and 24 columns, printed on two pages.  Each page can track 8 weeks; four weeks on one side, then rotate 180 degrees and 28 days on the other. 

When I opened it now, the occupied rows were black or bright green.  I rebuilt the tab from scratch on another tab.  First I copied the text.  Then I formatted the font and dates.  Then I set the column widths and row heights.  I added borders.  All was good.  But, when I rotated the text 180 degrees on the right two sets of 6 columns each, the background color changed.  When I tried printing it, there was a triangle printed on the background of each row.  The three corners of the triangle are the upper left of column A, the upper right of column X, and the lower right of column X.  The color of background is related to, but not equal to, the text color.

Steps to Reproduce:
1.Create a blank Calc sheet and select a cell
2.Add all borders
3.Rotate text 180 degrees


Actual Results:
entire row turns black on the screen.  A page wide, row high, triangle appears on printed page

Expected Results:
I would have a single, blank cell with a border.  Typed text would be upside down.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Other notes:================
The results vary the borders added and rotation amount.  The background color changes if the font color changes.

From Help-About=============
Version: 6.4.7.2
Build ID: 1:6.4.7-0ubuntu0.20.04.1
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 BugzillaReporter 2021-07-15 03:20:55 UTC
Created attachment 173587 [details]
Screenprint with poorly painted sheet

This is the page i came in to print.  Usually, I change the date in cell A2, and I am ready to print.

I added rows at the bottom to show what it looks like without rotation and without border.
Comment 2 BugzillaReporter 2021-07-15 03:23:58 UTC
Created attachment 173588 [details]
An .ods file with copy of sheet used to create screenshot
Comment 3 BugzillaReporter 2021-07-15 03:35:31 UTC
Created attachment 173589 [details]
An image of the printed Pages

i deleted the bottom rows and attempted to print as normal.  It should have filled up two pages.  Instead, I got three pages.

Note, the color is different on Saturday and Sunday.  I use different color text for weekends.
Comment 4 BugzillaReporter 2021-07-15 03:36:51 UTC
I noticed in prepping the attachments, the screenview will fix itself when scrolling.  Instead of the whole row being bad, it is just the cells with rotated text that are bad.
Comment 5 Buovjaga 2021-07-19 08:33:15 UTC
I confirm, but no problem when using the gen VCL backend

NixOS
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: b1df9c67349cf4cc5be4128d797aefb87f50e38f
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: x11
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded

Version: 7.1.4.2 / LibreOffice Community
Build ID: 10(Build:2)
CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Comment 6 Buovjaga 2021-08-03 15:38:31 UTC
Already seen in oldest of 6.3 bibisect repo, but not yet in 50max.

Windows also has a bad result, but the colour does not fill the cells fully, only by half. This is not seen with version 3.5.0 on Windows.
Comment 7 raal 2021-08-03 19:42:30 UTC
This seems to have begun at the below commit.
Adding Cc: to Armin Le Grand ; Could you possibly take a look at this one?
Thanks
bibisect-linux-64-6.0: e4982418b364315f649d2f1e15ac6656664786a4 is the first bad commit
commit e4982418b364315f649d2f1e15ac6656664786a4
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Sat Sep 16 01:19:32 2017 +0200

    source ab65fe804cf3a97bd172b5551b553b9bcde6d756

https://git.libreoffice.org/core/+/ab65fe804cf3a97bd172b5551b553b9bcde6d756
    borderline: Extended decompose
Comment 8 Armin Le Grand 2022-10-28 10:29:12 UTC
Taking a look...
Indeed happens as described using

Steps to Reproduce:
1.Create a blank Calc sheet and select a cell
2.Add all borders
3.Rotate text 180 degrees

(had to search to find how to do three :-))
It behaves differently when zooming in/out in EditView
-> It clearly has to do with borders, switching them off for that cell removes the problem
-> It also has to do with 180deg text, selecting cells around one with that text works, with and without text
-> Even without text, but 'Text orientation' set to 180 shows the error

AFAIR that 'Text orientation' not only rotates the text, but also the borders (looks strange from my POV). That may lead to numerical problems in the border handling/decomposition (?)
Comment 9 Armin Le Grand 2022-10-28 10:31:12 UTC
Playing around with 'Text orientation' shjows that it works with all values [0..359] except 180 -> hunting for the numerical problem...
Comment 10 Armin Le Grand 2022-10-28 10:40:32 UTC
Also works with
  "Text Extension Inside Cell",
breaks with
  "Text Extension From Lower Cell Border" and
  "Text Extension From Upper Cell Border".

Colored all 4 borders and checked that these get not rotated with the cell.
It works with "Text Extension Inside Cell" probably because this does not modify the cell border, just extends the call itself to make the text fit.
Comment 11 Armin Le Grand 2022-10-28 14:28:55 UTC
Identified the problem:
In Cell::HelperCreateB2DHomMatrixFromB2DRange a Shear/Skew is applied depending on the rotation. It is excluded for zero (IsRotated()) but not for mfOrientation == 3.1415926535897931 which is 180 degree (PI).
Thus

  const double fSkew(aY.getY() * (cos(mfOrientation) / sin(mfOrientation)));

is created as -5.5526213800864256e+17 due to sin(mfOrientation) being close to zero (numerical errors, it should be straight zero what would have led to division by zero and a crash). This is HUGE.
The rest of the double-precision mechanism creates the correct borders for that Skew, so what you see is the VERY far-stretched geometry of the border polygons.

This makes of course no sense, so it needs to be handled for PI/180 deg rotation. The text is drawn at ScOutputData::DrawRotated and use a Skew, too, so we should do the same correction as it has to be there already.
Unfortunately it also just works by chance - the eRotMode gets forced to SVX_ROTATE_MODE_STANDARD by

  if ( nAttrRotate == 18000_deg100 )
    eRotMode = SVX_ROTATE_MODE_STANDARD;    // no overflow

but still wild values for

                                    nCos = cos( nRealOrient );
                                    nSin = sin( nRealOrient );

get calculated, nSin (a double :-)) being also wild (1.2246467991473532e-16). All calculations use it, but due to being close to zero, it has no real influence -> nothing bad happens...

It *still* only corrects for 18000, not for 17999 nor for 18001, so we are lucky that only single degree values pop in from the UI side (not sure about UNO API or odf import...).

But it gives us no good hint how to correct it at Cell::HelperCreateB2DHomMatrixFromB2DRange. Have to think about a good solution...
Comment 12 Armin Le Grand 2022-10-28 15:41:38 UTC
Checking solution, limit to 1/2 degree minimum for borders and text to do it uniformly. Doing some more tests...
Comment 13 Armin Le Grand 2022-10-28 16:38:01 UTC
Fix looks good (for me), on gerrit:
https://gerrit.libreoffice.org/c/core/+/141999
Comment 14 Commit Notification 2022-10-31 09:02:17 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/604f6fc8fe7438f7cfbcfc8a3107ace59e950627

tdf#143377 Correct maximum Skew for TextOrientation in Calc

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Armin Le Grand 2022-11-01 10:14:33 UTC
Argh - a div by zero was found, thanks for finding and reporting, Noel!
Added https://gerrit.libreoffice.org/c/core/+/142098 to solve it...
Comment 16 Commit Notification 2022-11-01 11:29:27 UTC
Armin Le Grand (allotropia) committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/4e5df4c2777df3dcddffe0efdfceca55b3101bdf

tdf#143377 Handle nAttrRotate and Skew more backward safe

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.