Created attachment 164423 [details] Image showing the background color issue I usually prepare tables on LO Calc, with all the formatting. Then I copy and paste these Calc tables into an Impress presentation as OLE objects. However, there is a bug in this overflow that I have always noticed, which is a small offset in background colors (see attached image file, in the first row). I also attached the ODP file I was working on when I took the screenshot. Every time I copy a table from Calc and paste it into Impress as a Calc OLE object, the background colors of cells appear offset and it does not look good when I am presenting them. I have experienced this bug for a long time now, since LO 6.X... so I decided to file this bug report. I am using LibreOffice 7.0.0.3 on Ubuntu 20.04 (Gnome 3.36 and Nvidia graphics).
Created attachment 164424 [details] Impress file where I experienced the bug
Can anyone provide a code pointer for this bug? I don't know exactly where to look for this bug in the code. It seems to be related to how LO positions the rectangle corresponding to the fill color, so maybe it might not be such a complicated fix. So I'd like to take a look and see if I can manage it.
Created attachment 173682 [details] New Sample file Still present in LO Beta 7.2. I attached a new example showing the problem. System info: Version: 7.2.0.1 / LibreOffice Community Build ID: 32efc3b7f3a71cfa6a7fa3f6c208333df48656cc CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded
No repro in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 1dd4a80fa076bedb3a82821517036bad8dd79857 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-26_22:41:19 Calc: threaded Please upgrade your office to the latest version and try to reproduce bug.
Created attachment 174068 [details] ODG Point out the issue I really wish I could find a LO version where this issue is "not repro" as you said. I have been struggling with this issue since always. I attached 2 new files to clarify this bug. The first is an ODG image pointing out the problem and the second is the original ODP file with the problem. These were both created using LO Impress built from source with the latest code: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: b85becd0d427c7375f1d8e6309f348304b6ebbac CPU threads: 16; OS: Linux 5.11; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL The issue is still present in LO 7.2 beta1 as well.
Created attachment 174069 [details] ODP File with Calc Table This is the original ODP file used in the example above. It has a Calc table pasted as an OLE object into Impress.
Thank you for clarification, now i see the problem. Repro in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 1dd4a80fa076bedb3a82821517036bad8dd79857 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: ru-RU (ru_RU.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-26_22:41:19 Calc: threaded
This problem is still present in the latest LO 7.3 beta: Version: 7.3.0.0.beta1 / LibreOffice Community Build ID: 436f14c25ec1847646b953cf13d0db4f7ca3be57 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: threaded
*** Bug 161517 has been marked as a duplicate of this bug. ***
Created attachment 197628 [details] printscreen from 4.1 Tested with Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) As you can see, the shift of color was also in this version, but seems to be smaller.
Tried to investigate this error and don't know if it could be solved in an easy way. When you double click the OLE object you end up in the Calc mode with the following work flow: BACKGROUND: bMetaFile = true eType = OUTTYPE_PRINTER bWorksInPixels = false GRID (triggered by the repaint process): bMetaFile = false eType = OUTTYPE_WINDOW bWorksInPixels = true BACKGROUND (AGAIN): bMetaFile = false eType = OUTTYPE_WINDOW bWorksInPixels = true When you then exit the OLE object an return to Writer you end up in: BACKGROUND bMetaFile = true eType = OUTTYPE_PRINTER bWorksInPixels = false And there the problem arises since the GRID was drawn using pixels whereas the background was drawn now using logic units. Tried to draw the grid again but without any luck. I hope it works by just avoiding the adjustment: https://gerrit.libreoffice.org/c/core/+/182890
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/69bf9f849234f3adb678c254b8ec7dbb5824ed8b tdf#135891 - Don't adjust x and y coordinates when working logic units It will be available in 25.8.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.
*** Bug 99953 has been marked as a duplicate of this bug. ***
Created attachment 199809 [details] Result after first patch After the patch there is still some offset on the x-Axis. However, the y-axis should be fine now.
(In reply to Andreas Heinisch from comment #13) > *** Bug 99953 has been marked as a duplicate of this bug. *** In that case, taking over the regression details from that. See https://bugs.documentfoundation.org/show_bug.cgi?id=99953#c12 for the bisect. The bisect refers (among others) to the sc/source/ui/view/output.cxx file you updated on your comment 12, by the way.
See also the similar, but apparently older issue in Calc itself in bug 50289 (might be the same root cause).
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2eb8abda788e4f8c1b83281463673848c08ed6e0 tdf#135891 - Adjust the x position to ensure the correct starting point It will be available in 25.8.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.
Created attachment 199821 [details] screenshot Still an issue with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2eb8abda788e4f8c1b83281463673848c08ed6e0 CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Did you redraw the table by entering/exiting the spreadsheet in Writer? Otherwise, the issue still persits. May you attach a sample document?
Sent a new path. There is still an issue with borders and background colors at the beginning.
Created attachment 199830 [details] Problem first column There is still a problem at the first cell.
Created attachment 199835 [details] last-improvement There is still room for improvement. The main problem here is that the grid will not be redrawn. Hence, the patch tries to match logical units with pixels which is possible to an extent. The overall solution would be drawing the grid again but I could not succeed.
(In reply to Andreas Heinisch from comment #22) > There is still room for improvement. The main problem here is that the grid > will not be redrawn. Hence, the patch tries to match logical units with > pixels which is possible to an extent. > > The overall solution would be drawing the grid again but I could not succeed. Thank you for trying! I have no experience with the LO code, so just as a side note: The apparent regression patch (see comment 15 above) https://git.libreoffice.org/core/+/e24d47fb840c95ca247dda5c9d3acc106b8d6abc%5E%21 also touched the drawCells() function, which is called by the DrawBackground() (you updated) in two places - on lines 1218 and 1230. But neither the drawCells() itself, nor the calls to it consider your pixel/logical unit updates. Could those be the right places? (If I'm on a wrong path or you already considered that, please feel free to ignore this comment.)
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cef2ea134acf20ce3a1bcf681424b1ed2864f7db tdf#135891 - Adjust the x position to ensure the correct starting point It will be available in 25.8.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.
Still this patch handles only the symptoms until an extend. Drawing the grid again could be solve this problem but I could not suceed in doing so.