Bug 53287 - FORMATTING : cell border too bold when importing xls
Summary: FORMATTING : cell border too bold when importing xls
Status: RESOLVED DUPLICATE of bug 56960
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:3.7.0
Keywords: regression
: 50865 53302 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-08-09 10:38 UTC by fgruel
Modified: 2013-07-26 01:39 UTC (History)
21 users (show)

See Also:
Crash report or crash signature:


Attachments
file with problem (15.37 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)
2012-08-09 10:38 UTC, fgruel
Details
format comparison between XL and calc (450.56 KB, image/png)
2012-08-09 10:39 UTC, fgruel
Details
Font to border size comparison (1.20 KB, image/png)
2012-08-22 08:10 UTC, Stefan Knorr (astron)
Details
Comparison of format cells dialog to how it appears in the spreadsheet (40.62 KB, image/png)
2012-10-25 18:12 UTC, Mike
Details

Note You need to log in before you can comment on or make changes to this bug.
Description fgruel 2012-08-09 10:38:12 UTC
Created attachment 65340 [details]
file with problem

this file fits on a A4 page with XL and not with calc and border are far too bold.
see attached files
Comment 1 fgruel 2012-08-09 10:39:21 UTC
Created attachment 65341 [details]
format comparison between XL and calc
Comment 2 Michael Stahl (CIB) 2012-08-21 13:46:50 UTC
hmmm lines look much fatter than in older versions
Comment 3 Michael Stahl (CIB) 2012-08-21 15:46:23 UTC
*** Bug 50865 has been marked as a duplicate of this bug. ***
Comment 4 Michael Stahl (CIB) 2012-08-21 15:51:26 UTC
*** Bug 53302 has been marked as a duplicate of this bug. ***
Comment 5 Michael Stahl (CIB) 2012-08-21 16:10:50 UTC
i'll add 2 more bugs 2 this which are quite likely duplicates
(in case this is a painting problem independent of XLS import);
that makes 5 bugs with people complaining about too fat borders in Calc.
Comment 6 Markus Mohrhard 2012-08-21 23:28:34 UTC
(In reply to comment #5)
> i'll add 2 more bugs 2 this which are quite likely duplicates
> (in case this is a painting problem independent of XLS import);
> that makes 5 bugs with people complaining about too fat borders in Calc.

Actually this has been a bug for years in the OOo code. The code allowed to set borders in 0.01 steps but did not differentate in the view between borders of size 0.05 (minimal size) and 0.9, so there are quite many documents out there that will be printed correctly but that never were shown correctly in the view.

I know that it is nasty that these documents are now showing differently in the view but the same people complained before my change that the documents were not printed as tehy looked in the view and the old behavior was not consistent.

IMHO the solution is to limit to maybe 2 or 3 different border sizes like excel supports and map pt values to these border sizes. This is a question for the UX guys.
Comment 7 Stefan Knorr (astron) 2012-08-22 07:50:15 UTC
Is the border correctly displayed? If so, I'd argue we shouldn't make it very much thinner.

Although: Is it actually possible to use the exact measurements there or are spreadsheet dimensions inherently without a real-world equivalent?


(What we definitely should do is align borders to the pixel grid exactly – all the antialiasing there really doesn't help. And if we do that, we can probably also always shoot for a bit of added thinness.)
Comment 8 Stefan Knorr (astron) 2012-08-22 08:10:52 UTC
Created attachment 65940 [details]
Font to border size comparison

Okay, here's an attempt to solve the question whether or not the border is too thick:

Nominal Point sizes
===================
Font size: 8pt
Border width: 2.5pt

Ratio: 3.2

Displayed Pixel Sizes
=====================
Font size: 24px*
Border width: 11px

Ratio: 2.18

Conclusion here: border actually is too thick.


* Font size is measured from highest ascender to lowest descender, according to http://en.wikipedia.org/wiki/Typeface , thus I used the "Rg" string that, taken together, has both.
Comment 9 Michael Stahl (CIB) 2012-08-22 11:25:27 UTC
we definitely should do something about the anti-aliasing problem,
though i don't know what exactly.

there is apparently code in various places that tries to align
borders to pixels somehow but it seems none of that works anymore
since LO 3.4.

other than that perhaps there's some rounding error, iirc the border
line drawing layer primitives are created from the center of the border
and then adding half of the width in 2 directions, guess that could
make a difference in case we round up twice.
Comment 10 Markus Mohrhard 2012-08-27 20:03:56 UTC
Just to add some more details:

We may need to adjust the mapping excel border <-> calc border. Excel only knows about 4 different border sizes so we are mapping by our best knowledge to our own too complex border system.
Comment 11 Dag Wieers 2012-08-31 10:08:39 UTC
I contest that this bug existed for years, something is very different since 3.6.

I create timesheets in XSLX format for work using LibreOffice since at least LibO 3.4 every month. Only today (using 3.6.1) I have this problem that in fact corrupts the XLSX file itself. Because after saving the file in LibO, the thick borders are now also too thick in Excel.

I also contest that this is a display issue, because I export every month to PDF and the PDF too has a too thick border. This is a clear bug that is fairly recent and should be fixed as it affects too many people interoperating with Excel.
Comment 12 Roman Eisele 2012-09-05 15:34:47 UTC
Hint:
is bug 52578 - "Incorrect Cell Border Width After FILESAVE/Reload Via .xlsx Format" a duplicate, or at last related to this one?

The present bug is about .xls and bug 52578 is about .xlsx file format, but both file formats are related, and here comment #11 explicitely mentions .xlsx format.
Comment 13 Not Assigned 2012-09-18 18:21:39 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fac308c3641c55e12014613eb7fc09cb51039e44

adapt xls import of borders to new border drawing code, fdo#53287



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 Horst 2012-09-19 02:01:43 UTC
Just my thoughts: I must agree with Marcus Mohrhard (comments 6, 10). LOs border tweeking seems to me like overkill. Seriously who needs almost infinite border width. Let just define a few with 2 or 3 line width (ok the same like Excel) and we are fine.
Lotus 123 has only 5 borders.
I was playing around with the borders from LO3.5.5 to 3.6.2rc and it is a mess!!
Different pattern depending on pt-size. Somtimes doublelines don't show and don't print or barely distinguishable or only fat lines.
I say lets make a cut and kiss (keep it stupid simmple)
Comment 15 Roman Eisele 2012-09-19 06:43:59 UTC
(In reply to comment #14)
> (keep it stupid simmple)

I hope it’s the other way around: “let’s keep it simple, stupid” ;-)

(LibreOffice should work for stupid users, too, but the application itself should be simple, not stupid.)
Comment 16 Horst 2012-09-19 17:24:55 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > (keep it stupid simmple)
> 
It can also mean "keep it short and simple" and you know there is a very thin line between stupid and genius.
That all the fun for today :-)
Comment 17 Leif Lodahl 2012-10-11 18:23:12 UTC
When a user selects double border and doesn't get double border but single thick border, I can't see this as anything else than a serious bug. Many users choose double underline to mark the result cell. 

The problem occurs in ODS file, but becomes much more a visible problem when loading a document created in Excel. That might be reason for the confusion about whether this is a problem when loading files from Excel.

Mu suggestion is to change target to 3.6.

I tried the daily built of 3.6, but can't see any change. http://dev-builds.libreoffice.org/daily/Linux-x86_10-Release-Configuration/libreoffice-3-6/2012-10-08_15.52.02/

Do we need more example files to qualify the problem?
Comment 18 Mike 2012-10-25 18:12:57 UTC
Created attachment 69085 [details]
Comparison of format cells dialog to how it appears in the spreadsheet

I also agree with Dag Wieers that this is not an old bug, but a new bug in version 3.6 as this wasn't an issue for me with 3.5.2 (at least on Ubuntu). It is also NOT specific to Excel files, but even .ods files are giving me the same problem. The borders are significantly thicker than in previous versions of LibreOffice for exactly the same .ods file.

Also, when formatting the cells, the preview appears to display the borders correctly, while the actual spreadsheet is displayed with the thick border. I have attached a screenshot. This is also an .ods file with zoom set to 100% and anti-aliasing manually set to off. Turning anti-aliasing on (which it was by default) exaggerates this error even further.
Comment 19 Rainer Bielefeld Retired 2012-12-16 12:42:07 UTC
We have so many lots of descriptions for various different problems, existing or not, XLS relate or not in the comments here, it's more or less impossible to follow the discussion - its some horror. 

Please do some tests to problems related to Markus' Fix 2012-09-18 18:21:39 UTC, and then we should close this Bug, except a backport to 3.6 is planned.

For anything else not 100% related to the original report please submit new bugs (if not already reported), that's the only way ot keep overview.

@Markus:
Is it planned to backport the fix to 3.6?
Comment 20 Alejandro Moreno 2013-04-12 15:26:29 UTC
Problem still exists on Libreoffice 4.0.2.
Comment 21 Marian 2013-05-15 01:10:21 UTC
4.0.2.2: Ways to reproduce: (1) create a brand new spreadsheet; pick three cells not next to each other; for each of them, set the border respectively 0.05, 0.5 or 0.8, 1.05; (2) save the file as xls, as xlsx, or ods.; (3) re-open each of the files: xls and ods are OK, xlsx is wrong.

Problem: xlsx stores the border thickness as "", "hair", "thin", "thick"; when opening "thin" it makes it 1pt, however, when saving 1pt, it saves it as "thick". Definitions of borders are in file styles.xml, found under \test.xlsx\xl\ (where test.xlsx is my test file). Open xlsx with 7z same as an archive.
Comment 22 Kevin Suo 2013-07-26 01:39:31 UTC
This issue was fixed in 4.1 as discussed in Bug 59690, so I change status to RESOLVED DUPLICATE.

However, it still exists in 3.6.7 release.

*** This bug has been marked as a duplicate of bug 56960 ***