Problem description: Cell borders drawn in calc using python scripts do not draw as expected in all cases. If either of the com::sun::star::table::BorderLine attributes LineDistance and InnerLineWidth is non-zero no border is drawn and any existing border is cleared. Steps to reproduce: Installed the attached script in your Scripts/python directory. Open a new calc document. Run the three macros implemented in the script from the UI. Current behaviour (3.6.3): The macro thinBorder will draw a thin border line around the current selection. The macro thickBorder will draw a thick border line around the current selection. The macro doubleBorder does not draw a double line around the current selection. Expected behaviour (3.5.7): The macro doubleBorder will draw a double line around the current selection. Platform (if different from the browser): Debian GNU/Linux 6.0.5 (aka Squeeze, aka Stable) Installation media: LibO_3.6.3_Linux_x86-64_helppack-deb_en-GB.tar.gz LibO_3.6.3_Linux_x86-64_install-deb_en-US.tar.gz LibO_3.6.3_Linux_x86-64_langpack-deb_en-GB.tar.gz LibO-SDK_3.6.3_Linux_x86-64_install-deb_en-US.tar.gz
Created attachment 69778 [details] python script to demonstrate the problem
See 45645 - this is a similar bug reported in 3.4 that fixed itself. This reports a bug in 3.6. It may be that the bad behaviour of 3.4 has reappeared. Dunno. I don't have 3.4 to test.
This issue IS present in LibreOffice 4.0.0.
This issue IS still present in 4.0.3.
Problems persists in 4.0.6, 4.1.5 and 4.2.0.
I have no idea if the python code is valid (or not) but I can observe the described behaviour using the provided script. Confirmed under GNU/Linux x86_64 using: OK - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b not OK - v4.2.5.2 Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5 not OK - v4.4.0.0.alpha0+ Build ID: 4aa9b041de3129f19b48e66d349f48657b73f33e (2014-07-19) Status set to NEW.
** 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 on a currently supported version of LibreOffice (5.0.0.5 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Dear LibreOffice QA Team, I can confirm that the undesirable behaviour is still present in LibreOffice 5.0.2. There have been thousands of bug fixes and commits since anyone checked on this bug report BECAUSE I STILL USE LibreOffice 3.5.7 and there seems little point in going to the trouble of installing a new version each month just to confirm that the Bugzilla status is unchanged. During that time, the details of the problem have changed, Yup, THEY HAVE GOT WORSE: there is a rendering issue now as well and a data entry issue. Install yourself 3.5.7 and use the Python macros attached to create a thin, a thick and a double border round disjoint selections of your choice in a new calc workbook. You will see the results are nice and reasonable. Save the workbook and re-open in it 5.0.2. The thick border now appears as a thin border (regression since 3.6.3) while the double border looks a little off in the corners (regression since I don't know when). Now create a new workbook in 5.0.2 and use the Python macros as before. The thick board macro produces a thin border and the double border macro produces nothing (it will in fact clear any existing border). Save the workbook and re-open in 3.5.7, The thick border now appears as it should but there is no sign of the double border. If someone at the DF were to show an interest in this I could do more testing but my previous experience of trying to fix Open Source bugs is that fixes from folks the developers have never heard of have, well, snow ball and hell come to mind. I could re-implement the macros in OO Basic to prove the data entry problem is or is not pyuno specific. I have run git bisects in the past to isolate regression problems, Is your code base suitable? I have the impression that the implementation of cell borders was something that changed significantly between 3.5 and 3.6 so isolating the pertinent commit might not be helpful.
** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
Thank you QA team for your renewed interest. Another year has passed. It is now four years since I reported this bug and its status is still NEW. Did any one read the comment I wrote last year I wonder ? Will anyone read this year's comments ? This bug is a regression introduced between 3.5 and 3.6. The bug is in com::sun::star::table::BorderLine. It was introduced with the release that added com::sun::star::table::BorderLine2. I strongly suspect the new class broke the old one: it is a regression. There is nothing in the on-line LibreOffice documentation of com::sun::star::table::BorderLine to indicate that there is an alternative implementation in com::sun::star::table::BorderLine2. There are now notes on the CellProperty Service Reference against the new public attributes saying they are to be preferred over old attributes but not vice versa. Not very clear or satisfactory. Preferred is not the same as deprecated. I did some trials and although I found com::sun::star::table::BorderLine2 far from 'nice' it did at least not have the awful broken behaviour of com::sun::star::table::BorderLine reported in the original problem description of this bug report that has since got worse, not better. So I switched to using com::sun::star::table::BorderLine2 despite the not-so-good corner aesthetics. From my perspective, if the project were to update the on-line documentation of com::sun::star::table::BorderLine to state that this class is deprecated and folks should use com::sun::star::table::BorderLine2 instead, I would be happy to see this bug report closed. However, before you congratulate yourselves on another zero effort bug fix, consider importing an Excel spreadsheet. I use LibreOffice (d'oh) and have never used Excel except as a data format. However, I recall, that, in an attempt to prove this bug report was not Python specific, I did trying importing into LibreOffice 5.1.x an Excel spreadsheet that used cell borders. I'm pretty certain the imported LibreOffice spreadsheet used com::sun::star::table::BorderLine and not com::sun::star::table::BorderLine2. Perhaps you might want to check that, raise another bug report and close this one as a duplicate. Oh, BTW, bad behaviour sill there in 5.2.3.
** 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
Tested with Linux bibisect repository 43all on Ubuntu 14.04. I tried last35onmaster (3.5.0), last36onmaster (3.6.0alpha1), 3.6.0alpha0, but I can't see the expected result. Thus I am unable to bibisect. Script was placed in opt/share/Scripts/python directory so I could run it.
pls. have a look at https://bugs.documentfoundation.org/show_bug.cgi?id=126058 and https://ask.libreoffice.org/en/question/253532/calc-setting-borders-via-a-macro/?comment=253617#post-id-253617 similar problems with basic macros, i didn't test but it sounds like there is a solution - not a fix but a 'better practice' workaround? - by 'use of the Table2 and Border2 objects rather than the more obvious Table and Border objects', might help or give a hint for this case too? @Buovjaga: does your comment mean (3.5.0) failed for you too? @Owen reported 'OK - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b' @all: does anyone feel the gentle sarcasm of a frustrated user who - 4 more years ago now - expressed himself in such lines? > Thank you QA team for your renewed interest. > Another year has passed. It is now four years since I reported this bug and > its status is still NEW. > Did any one read the comment I wrote last year I wonder ? Will anyone read > this year's comments ? LO should really get faster in error handling ...
(In reply to b. from comment #13) > @Buovjaga: does your comment mean (3.5.0) failed for you too? @Owen reported > 'OK - v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b' Yes.
Dear Forester, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug