Created attachment 125172 [details] example odt: edit the calc table and the resulting pdf shows the error When inserting a calc table with colored cells in a writer document, the color is misaligned in the printout and pdf. in libreoffice 4.4 and 5.0 everthing works as expected. tested it with 5.2 and the error is still there.
Created attachment 125173 [details] correct printout made with 4.4 or 5.0
Created attachment 125174 [details] printout with misaligned color after editing calc table with 5.1
When you say misaligned, are you referring to the white space between the cell's color and the right cell border?
yes ... if you compare the two attached pdfs it should be clear what i mean. it seems that the offset between color and cell border is sometimes bigger and sometimes smaller. in the simple uploaded test.odt the difference is rather small, but i have documents where the difference is more obvious.
I uploaded another example where the error is more obvious
Created attachment 125189 [details] another example where the error is more obvious
Created attachment 125190 [details] pdf created from example2 where the error is more obvious
I confirm. It depends on the zoom level, no need to create a PDF. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: 60041cb237ea73c2c1885dd6afd99d88780c2dfc CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on May 26th 2016
Created attachment 127680 [details] Screenshot showing the issue I can confirm this as well. When a Calc table is pasted into Writer with (some of) its cells having background filling, the filling becomes misaligned with respect to the cell borders. Test procedure: 1. In a new Calc document, fill a few cells in a column with text and set their background filling to any color 2. Apply all borders to the affected cells 3. Select the affected cells as well as their neighboring cells and paste that into a new Writer document Expected results: 3. Cell background filling is aligned to the cell borders Actual results: 3. Cell filling is moved up-left with respect to the cell borders The issue is also visible in the resulting PDF document if the Writer document gets exported to PDF. Tested with: - Linux Mint 17.1, 64-bit: Version: 5.1.5.2 Build ID: 1:5.1.5~rc2-0ubuntu1~trusty1 CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; Locale: de-DE (en_GB.UTF-8); Calc: group - Windows Vista, 32-bit: Version: 5.2.2.2 Build-ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad CPU-Threads: 2; BS-Version: Windows 6.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group - Debian, 32-bit: Version: 5.3.0.0.alpha0+ Build ID: d15082cac2306fb9562ff126eb5827b7b9eee1e1 CPU Threads: 2; OS Version: Linux 4.6; UI Render: default; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-09-19_05:41:30 Locale: en-US (en_US.UTF-8); Calc: group The issue seems to be a regression in LO 5.1. LO 4.0.4 and 5.0.5 do not show the issue (tested as portable releases on 32-bit Windows Vista).
The issue is especially striking on paper-printouts, where it looks like printer misalignment (tested printing out exported PDF document).
Thanks for the regression test, Johnny.
This seems to have begun at the below commit. Adding Cc: to Krisztian Pinter ; Could you possibly take a look at this one? Thanks author Krisztian Pinter <pin.terminator@gmail.com> 2015-06-14 18:38:26 (GMT) committer Jan Holesovsky <kendy@collabora.com> 2015-07-24 08:52:04 (GMT) commit e24d47fb840c95ca247dda5c9d3acc106b8d6abc (patch) tree e53a3817386a681016bca2939c1924f3ce228c69 parent 724249cebb5793fb3d46e011269cabb03e3aa1b9 (diff) calc mapmode: Refactor DrawBackground to use logic units git bisect log # bad: [05d11632892a322664fb52bac90b2598b7fb7544] source 5616d22b57a9a5e57d545e912e029162a230829b # good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65 git bisect start 'origin/master' 'oldest' # bad: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source 4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f git bisect bad 97526ab777da7e58ce283c05498262ecdd4d6f7f # good: [2202cdaa0eae3f646f1285a0ea45934edeb26e8a] source a88bf8fd10c42a15e5d6e66da656889c82b4933a git bisect good 2202cdaa0eae3f646f1285a0ea45934edeb26e8a # bad: [13169de9868218d603d1ae26805ebf4583e7d628] source 6f98a0ab51cc5c860576b4ad44478b438cc5a5eb git bisect bad 13169de9868218d603d1ae26805ebf4583e7d628 # good: [a2e73a5257c1598c1070ec06105c1dffaef3842e] source 01d1165572f53ca50c626fa036343932c1e8c5db git bisect good a2e73a5257c1598c1070ec06105c1dffaef3842e # bad: [3537cdbd10dfe084536e29e5f67ae7504c7c48b6] source a99520eb0a0ccb5a03e85c697d38eb6520ec403c git bisect bad 3537cdbd10dfe084536e29e5f67ae7504c7c48b6 # bad: [beb18a387facf7b7433ea64c9f5711e268890ede] source 8f7978245471763e5a2394cc8e67fed33483fe68 git bisect bad beb18a387facf7b7433ea64c9f5711e268890ede # good: [7e76bf68c8f32cdf2f13d14c6cf7a22114d6637a] source 26e6d4b05ab444e6a7529ffcac7fbe592fc94833 git bisect good 7e76bf68c8f32cdf2f13d14c6cf7a22114d6637a # good: [fabac0866e8aec1d20d002c53b3972e8c921bb66] source 9e28cc8ca79b5c42955867a62e89faf8facc5e80 git bisect good fabac0866e8aec1d20d002c53b3972e8c921bb66 # bad: [e7652a0b7696d751e1049cad13f68a8711048cd4] source e6e193afd56c7f1bb4625576d538573caf0f2bf1 git bisect bad e7652a0b7696d751e1049cad13f68a8711048cd4 # bad: [ba3330e4ccd8e69430b0e336d05dbd6465e9481e] source 450727fdffa4a0dc3b2d4e635a5c1bc0411b3c36 git bisect bad ba3330e4ccd8e69430b0e336d05dbd6465e9481e # bad: [1ab7485ae6d05e11a3a822d8ccb701b82a0b852d] source 7c927b64fa42ea1b0ddf97ce6b6aa400f2e30d5b git bisect bad 1ab7485ae6d05e11a3a822d8ccb701b82a0b852d # good: [de397ea78270ccb6072d1b047c02cde70af00d4d] source 724249cebb5793fb3d46e011269cabb03e3aa1b9 git bisect good de397ea78270ccb6072d1b047c02cde70af00d4d # bad: [e194318fa36c5efd6e41faf9eeae14d47ef01b9f] source e24d47fb840c95ca247dda5c9d3acc106b8d6abc git bisect bad e194318fa36c5efd6e41faf9eeae14d47ef01b9f # first bad commit: [e194318fa36c5efd6e41faf9eeae14d47ef01b9f] source e24d47fb840c95ca247dda5c9d3acc106b8d6abc
See also the similar, but apparently older issue in Calc itself in bug 50289 (might be the same root cause).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Error is still present in Version 6.1.0.3. No need to make a PDF. Error is now obvious on the screen. Error is not present in Version 3.3.4 and in 4.2
Same problem with version 6.1.2.1 (Build ID: 65905a128db06ba48db947242809d14d3f9a93fe)
This problem has been open for almost three years. Concretely, it makes it impossible in demanding contexts to publish ODT reports including OLE ODS. The severity of the ticket could be revised upwards? If "no", what is the position of developers on this need. Are there any solutions of contournelent?
This problem is now open for about 4,5 years or since two major versions and still no change. Is there anything that could be done from a non-developer to help fixing this issue?
Still repro in Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: ca47989ad60b1414f92be22a1fbf4c1d1a92dd97 CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL
updating the fields according to raal's bibisect. I can confirm that it started in 5.1. However, to confirm the "good" behaviour before 5.1, make sure to double-click into the embedded table to refresh it. Still reproduced in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e9374f74385d7dfe77d1902d3d82af20143bc775 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded