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.

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.

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.

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.

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 kiaora-paora,

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