Bug 58356 - Imported XLSX files show too thick table borders
Summary: Imported XLSX files show too thick table borders
Status: RESOLVED DUPLICATE of bug 56960
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
: 59582 59589 64120 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-16 10:52 UTC by Cailly Philippe
Modified: 2015-12-16 22:31 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
spreadsheet .xlsx to show problem (5.60 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2013-05-01 21:15 UTC, Tim Richardson
Details
screen shot (50.76 KB, image/png)
2013-05-01 21:16 UTC, Tim Richardson
Details
Shows borders before and after saving (135.75 KB, image/jpeg)
2013-05-01 22:49 UTC, lufferov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cailly Philippe 2012-12-16 10:52:12 UTC
Tables created with Excel in XLSX format show a very tick cell borders when imported in LO
Comment 1 Thomas van der Meulen [retired] 2012-12-18 21:00:14 UTC
what doe you mean with tick cell borders the line betwine j-k and betwine 48-49? 
or els i down't understand. or put a screen shot so i can see
Comment 2 john.pratt 2012-12-21 16:40:29 UTC
@Cailly Philippe
Can you provide the file that is causing this problem please.
Comment 3 paulchen 2012-12-23 13:20:42 UTC
I can confirm this bug in LO4.000b2 (Windows): a table crated with Calc and cell borders of default 1 pt width, saved as XLSX and then reopened in Calc has 4 pt wide borders.
Comment 4 Joel Madero 2013-01-20 00:09:46 UTC
*** Bug 59582 has been marked as a duplicate of this bug. ***
Comment 5 Tim Richardson 2013-01-20 00:57:25 UTC
In Bug 59582 (duplicate) I include an .xlsx and a screen shot.
Comment 6 Joel Madero 2013-05-01 17:34:25 UTC
*** Bug 64120 has been marked as a duplicate of this bug. ***
Comment 7 Tim Richardson 2013-05-01 21:15:36 UTC
Created attachment 78741 [details]
spreadsheet .xlsx to show problem

spreadsheet to show border conversion problem
Comment 8 Tim Richardson 2013-05-01 21:16:20 UTC
Created attachment 78742 [details]
screen shot
Comment 9 Tim Richardson 2013-05-01 21:23:40 UTC
So open the .xlsx in LibreOffice. The borders in that document are default Excel borders; they should be thin.
When I open it in LibreOffice 4.0.3.1 they are massively thick.
The situation has regressed compared to when I took the screen shot.
Comment 10 lufferov 2013-05-01 22:49:45 UTC
Created attachment 78743 [details]
Shows borders before and after saving

Image on the left side shows how the borders were created in Libre Office. After saving as an .xlsx file and re-opening in Libre Office, all cell borders have been changed to 4pt!

This is clearly a big problem and has been in Libre Office for a very long time!
Comment 11 ign_christian 2013-05-18 09:11:27 UTC
*** Bug 59589 has been marked as a duplicate of this bug. ***
Comment 12 Kevin Suo 2013-05-23 08:22:53 UTC
1. Create a new spreadsheet;
2. enter some "test" text in some cells;
3. apply "border:1.00pt" for these cells;
4. save as "Office Open XML" or "MS Office 2007/2010 XML" (.xlsx);
5. Open the file again, you will see the border is "4.00pt" thick;
6. When re-formated the border to be "0.50pt", it's "1.00pt" when re-opened;
7. When re-formated the border to be "0.30pt", it's "1.00pt" again when re-opened;
6. When re-formated the border to be "2.00pt", it's "4.00pt" when re-opened, which is the same is item "5" above.

Thanks for fixing this.
Comment 13 ign_christian 2013-05-27 16:01:28 UTC
confirm reproducible on LO 4.0.3.3 (Win7 32bit)

rechanging: 
Version : 3.6.2.2 -> oldest version known (Bug 59589)
Platform: All -> affects Win7, Mac, Linux 32& 64bit
Importance : ? -> let QA decide
Comment 14 Jorendc 2013-05-27 20:10:57 UTC
Please do not mark such bugs as HIGHEST BLOCKER.

If everyone is going to mark his bug as the highest possible, we better can delete the priority field because there is no distinction anymore.

1) This bug does NOT result in a crash/dataloss or broken core function
2) This is a "closed/proprietary extension", use ODS if you want to be 100% compatible with LibreOffice/other ODF-supporting software.

I'm going to mark this as:
* Normal: does prevent you to create high quality work
* High: higher then the default 'medium'. 

Although this, this bug looks like a duplicate of Bug 56960
Comment 15 Jorendc 2013-05-27 20:16:13 UTC
On the IRC channel (#libreoffice-qa) we discussed this one. We agreed this looks like a duplicate of bug 56960, so I'm going to mark it as such.

To all: if this bug is still reproducible when, while bug 56960 is still reproducible, please REOPEN this bug.

I hope you understand,
Joren

*** This bug has been marked as a duplicate of bug 56960 ***
Comment 16 lufferov 2013-05-27 20:19:43 UTC
You know what's really frustrating, I've been tracking this bug for months and months. Bug reports get opened, marked as duplicates, moved around, re-named etc.. just about everything imaginable. If the same amount of effort had been put into fixing the bug as has been invested in pushing it around in this system it would be resolved by now!
Comment 17 Jorendc 2013-05-27 20:27:46 UTC
(In reply to comment #16)
> You know what's really frustrating, I've been tracking this bug for months
> and months. Bug reports get opened, marked as duplicates, moved around,
> re-named etc.. just about everything imaginable. If the same amount of
> effort had been put into fixing the bug as has been invested in pushing it
> around in this system it would be resolved by now!

Still no legit proof this isn't a duplicate of bug 56960. As I said: only reopen/unduplicate this bug if the original bug is fixed, and you still can reproduce this behavior.

PS: it would also help not to re-mark bugs wrongly, so we can concentrate us on more important bugs like crashers/ODF bugs/etc etc instead of re-marking bugs over and over. With all my respect, but you have to thanks Microsoft that xlsx is proprietary, instead of ranting about people who volunteer to keep our bug database as clean and clear as possible, without loosing valuable information, and developers, were approx 50% of them are paid, 50% are doing this for free/voluntary.

PS2: if you can fix it by yourself, please do. Others will thank you! If you can't... <I don't have to say this>

*** This bug has been marked as a duplicate of bug 56960 ***
Comment 18 Tim Richardson 2013-05-27 21:07:01 UTC
I find this DUPLICATE resolution very disappointing.The new master bug addresses multiple issues which are unrelated except that they are broken import features. So the scope goes from specific to obscure. Why not just replace the entire bug tracker with one bug? If you merge too many problems into one bug then how do we have a bug tracker? I proposed this as an easyhack but no one is going to consider the master bug as an easyhack because it is really 7 different but reports. 
This bug of course affects only the minor use case of people who want to use the same spreadsheet across excel and LO. Like in all those migration to LO whitepapers. In my case i teach a small business financial planning course. This bug is the only reason i have to tell my students to buy ms Office (because we will not maintain a specific version of templates for libreoffice.)
Comment 19 Jorendc 2013-05-27 22:13:28 UTC
Please stop this mark-war and read https://wiki.documentfoundation.org/QA/BugTriage#Step_2._Search_for_Duplicates instead. You are spamming users inboxes, who follow the workflow. 

If you, after reading that, still think our workflow isn't right (and no, I'm not the founder of this workflow), please join us on #libreoffice-qa (http://webchat.freenode.net/?channels=libreoffice-qa) or the qa-mailinglist (http://www.libreoffice.org/get-help/mailing-lists/), join a QA-Call (https://wiki.documentfoundation.org/QA_Call_Current_Agenda#Next_Meeting.2FUpcoming_Meetings) instead of staring a war out of it.

Marking this bug as a duplicate is the only way to go. If it proves it isn't a duplicate, which means you can provide code pointers (http://opengrok.libreoffice.org/), a patch, or Bug 56960 is fixed and this is still reproducible, we can mark this back to NEW.

Kind regards,
Joren

*** This bug has been marked as a duplicate of bug 56960 ***
Comment 20 Robinson Tryon (qubit) 2015-12-16 22:31:19 UTC
Migrating Whiteboard tags to Keywords: (ProposedEasyHack -> needsDevEval)
[NinjaEdit]