Download it now!
Bug 56894 - FORMATTING: Cell borders drawn using (python) scripts do not draw as expected in all cases
Summary: FORMATTING: Cell borders drawn using (python) scripts do not draw as expecte...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: bibisectRequest, regression
Depends on:
Blocks: Cell-Border
  Show dependency treegraph
Reported: 2012-11-08 22:29 UTC by Forester
Modified: 2020-06-05 12:07 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

python script to demonstrate the problem (1.45 KB, text/x-python)
2012-11-08 22:32 UTC, Forester

Note You need to log in before you can comment on or make changes to this bug.
Description Forester 2012-11-08 22:29:06 UTC
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:
Comment 1 Forester 2012-11-08 22:32:23 UTC
Created attachment 69778 [details]
python script to demonstrate the problem
Comment 2 Forester 2012-11-08 22:34:51 UTC
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.
Comment 3 Forester 2013-03-20 19:10:48 UTC
This issue IS present in LibreOffice 4.0.0.
Comment 4 Forester 2013-05-13 19:45:06 UTC
This issue IS still present in 4.0.3.
Comment 5 Forester 2014-02-24 21:41:22 UTC
Problems persists in 4.0.6, 4.1.5 and 4.2.0.
Comment 6 Owen Genat (retired) 2014-08-01 13:43:17 UTC
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.
Comment 7 QA Administrators 2015-09-04 02:48:34 UTC Comment hidden (obsolete)
Comment 8 Forester 2015-10-20 14:28:52 UTC
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.
Comment 9 QA Administrators 2016-11-08 11:26:50 UTC Comment hidden (obsolete)
Comment 10 Forester 2016-11-15 17:01:12 UTC
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.
Comment 11 QA Administrators 2018-09-18 02:50:30 UTC Comment hidden (obsolete)
Comment 12 Buovjaga 2020-06-05 12:07:13 UTC
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.