Created attachment 64380 [details] screenshot 3.5.5 in a calc-file the line width of the border is shown much too big. attached screenshots from the same file, opened with 3.5.4 and 3.5.5.
Created attachment 64381 [details] screenshot 3.5.4
It is the other way around. The old ones were too small. Just compare the lines produced in 3.5.4 between 0.05pt and 0.9pt. They are all painted with the same line width to the screen but there are some formats where they have always been printed correctly which resulted in quite a large number of problems.
Created attachment 64593 [details] Border Width in Spreadsheets in LibreOffice 3.5.5.3 I have reopened this bug because I believe the current state is not the best solution. Please take a look at the attached image: it shows a screenshot of border widths, next to an exported PDF and a comparison with InDesign line-widths. The PDF export is quite good (apart from the border at 0.05pt appearing the same as 0.5pt) but the on-screen representation of border widths could be improved: the change from 0.3pt to 0.4pt seems much too big compared to the change from 0.25pt to 0.3pt. It is also worth keeping in mind that 0.05pt equals 0.018mm and lines smaller than 0.1mm are very hard to print.
I have the same problem in windows 7 (32 bit) - pdf export and opening the file in other programmes are consistent and look as in 3.5.4.
Created attachment 80262 [details] Example cell border widths (ODS/PDF/PNG) showing on screen display and export to PDF. I am re-closing this bug for a number of reasons: 1. The initial bug as described appears to relate to a change with v3.5.5.3 that altered how cell borders were displayed. Markus has indicated in comment #2 how this was actually a rectification of a previous problem. That problem is clearly outlined in bug #51178 which was closed as NOTABUG. 2. No indication of file format (ODS/XLS/XLSX) is provided in either the description or comments. There are other bugs relating to XLS/XLSX issues with cell borders such as bug #52578, bug #53287, and bug #56960. Comments in all those bugs, particularly the last two, are informative of the nature of the various problems. 3. No example files are provided. I have provided a basic example (with slightly different values) in https://bugs.freedesktop.org/show_bug.cgi?id=52578#c5 I am also attaching a further sample here in keeping with the graphic provided in comment #3. I do this in the spirit of goodwill as there are a couple of issues here, however ... 4. It appears to me that comment #3 has effectively re-purposed this bug. Rather than doing so in the generic manner indicated I would suggest raising a new bug (if none already exists) to address the more specific nature of what appears to be these concerns. I will detail what I see these concerns as below. 5. The reference to InDesign, while illustrative, carries little weight. Calc is spreadsheet software, while InDesign is desktop publishing software with no equivalent in LO. Interoperability with OOXML is a far more powerful argument and it only supports four different cell border widths (as I indicate in the comment I refer to above). It is quite likely that LO will head in this direction in order to simplify both the required code and interoperability. That is how I am interpreting the comments by developers in the linked / related bugs. The issues raised in comment #3 are effectively two: a) cell border of 0.05pt (a.k.a. "hair" in OOXML) does not export to PDF correctly; b) the on screen display of cell borders does not accurately resolve widths in the ranges 0.05-0.39pt and 0.40-1.00pt. (a) looks to me like a bug. This hairline weight is not be treated correctly during export to PDF. There may be a fix for this in v4.1.0.0. I have not looked at that. (b) Markus sums this up neatly in https://bugs.freedesktop.org/show_bug.cgi?id=53287#c6 Until the UX team come back with an answer there is little the developers can do. He also made a patch back in September 2012 to adjust the XLS import values from 24 to 16 ("thick"), 18 to 12 ("medium"), and 6 to 4 ("thin") which may have a bearing here if XLS is being used.
Re-closing (RESOLVED/NOTABUG) as per comment #5. If someone wants to re-close as a duplicate of one of the indicated bugs, please do so.