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
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.
Created attachment 173588 [details] An .ods file with copy of sheet used to create screenshot
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.
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.
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
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.
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
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 (?)
Playing around with 'Text orientation' shjows that it works with all values [0..359] except 180 -> hunting for the numerical problem...
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.
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...
Checking solution, limit to 1/2 degree minimum for borders and text to do it uniformly. Doing some more tests...
Fix looks good (for me), on gerrit: https://gerrit.libreoffice.org/c/core/+/141999
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.
Argh - a div by zero was found, thanks for finding and reporting, Noel! Added https://gerrit.libreoffice.org/c/core/+/142098 to solve it...
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.