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
Created attachment 65341 [details] format comparison between XL and calc
hmmm lines look much fatter than in older versions
*** Bug 50865 has been marked as a duplicate of this bug. ***
*** Bug 53302 has been marked as a duplicate of this bug. ***
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.
(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.
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.)
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.
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.
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.
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.
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.
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.
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)
(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.)
(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 :-)
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?
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.
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?
Problem still exists on Libreoffice 4.0.2.
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.
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 ***