In the attachment is "Some lines do not print.ods" created from the original .xls, with 2 tabs: original tab where "Some lines do not print" and new tab where "Reapplied border lines do print". As name suggests, I had to reapply cell borders to have them printed properly. I used PDF but it's the same with printer. I couldn't find this. There is a similar title "EDITING and VIEWING cell borders differs from expected and PRINTING" at https://bugs.freedesktop.org/show_bug.cgi?id=42339 but it doesn't look the same to me. PDFs will also be attached.
Created attachment 57390 [details] LO bug 46393 - Some lines do not print
Created attachment 57391 [details] LO bug 46393 - Reapplied border lines do print
Created attachment 57392 [details] LO bug 46393 - Some lines do not print.ods
The same "Some lines do not print" tab from "Some lines do not print.ods" prints correctly with OO 3.3.0.
Created attachment 57449 [details] LO bug 46393 - Same lines do print in OO (PDF)
reproduced in 3.6.0 master 97fdf02-9eed775-f061262 on Fedora 64 bit PDF exporter dislikes line width 0,3 pt. And when I changed slightly this file, saved under another name and verified in site http://odf-validator.rhcloud.com/, some error in ods file found: LO bug - Some lines do not print-1.ods/styles.xml[119,332]: Error: unexpected attribute "style:scale-to-X" LO bug - Some lines do not print-1.ods/content.xml[108,519]: Error: attribute "style:text-position" has a bad value
reproduced in 3.4.2, but not reproduced in 3.3.4, therefore regression since 3.3.4
@ Kohei Please, take look at this when will have time. Regression since 3.3.4 in exporting to pdf.
I see the effect with "LibreOffice 3.5.0 German UI/Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit) For example cell Q14 seems to have black border 0,05pt all around (I checked with a.m. version), but in the PDF only the left border looks like black 0,05pt. With different zoom affected borders look different in PDF. My lossles PDF export result is horrible, unusable,look much worse in AR-X than reporter's PDF example (see attachet results). Not a 3.5.0 problem, I see the same with 3.4.5 and 3.4.1RC, I believe it started with 3.4.0 Borders look fine in export from 3.3.0 document.xls related, no problem with self created documents from LibO 3.3.0 So more or less confirmed all of sasha's observations - I was a little late
Created attachment 57470 [details] test results Borders in exports from versions later than 3.3 look horrible in AR-X
Suspected duplicate of Bug 33634
Markus Mohrhard wrote on 2012-04-02: "Bug 46393 is a suspected duplicate of Bug 33634." In Bug 33634 Markus Mohrhard wrote on 2012-04-03: "I have finally a fix for Bug 33634 that will not make it into 3.5! If you wanna help grab one of the next daily master builds and check all kind of features around borders: Displaying in different zoom modes, printing, export to pdf, and everything that I missed right now..." I grabbed http://dev-builds.libreoffice.org/daily/Win-x86@6-fast/master/2012-04-04_00.12.53/master~2012-04-04_00.12.53_LibO-Dev_3.6.0alpha0_Win_x86_install_en-US.msi. is it the right build? There is no description which Windows build is right. And I don't know if I'm early. But, the problem from Bug 46393 remained with this build.
@gtimur@gmail.com: In the same folder like the master.msi you find a text document with information tinderbox: pull time 2012-04-04 00:12:53 (no time zone mentioned) The commit is from 2012-04-04 01:09:48 (GMT) That's at least quite nearby, I would wait 1 day to be sure that the commit is in the build.
You can easily check if you compare borders of different width in the grid. If they looks the same you don't have a build including the fix otherwise you have one. You can easily compare to 3.5 to check if it changed.
I tested also with http://dev-builds.libreoffice.org/daily/Win-x86@6-fast/master/current/master~2012-04-04_23.10.16_LibO-Dev_3.6.0alpha0_Win_x86_install_en-US.msi. While in Bug 33634 table looks different with that version, the same problem remains here. It looks to me that this is not a duplicate.
yeah lines are 0.05pt could be the hairlines problem detection part of bug 33634, and the regression bug 49483 introduced by the fix for that (did i ever test if that affects PDF?), but this is also affected by PDF reader's inability to properly display lines less than 0.15pt or so (bug 40289). if i print the _first_ sheet bugdoc added in comment #3 with LO 3.5.4 and look at it with evince it's pretty awful, and ~current master looks the same. but the questionable hack i proposed for bug 49483 does make quite a difference: with evince at 400% all lines are visible, though at lower zoom levels some lines disappear (as described in bug 40289); perhaps with the rounding up to 0.15pt in PDF export proposed in that bug this one could be fixed...
Created attachment 67259 [details] LibreOffice_Test-Sample_Menu-Format-Cell-Borders_V01_LiboV3621_en-us I was found that I can not get what I expect setting cell borders. To help in see the issue I have made a file test. -For the eight line types. -With five widths for each line type: 0.05 0.25 0.50 1.00 2.00. -With a defined style for everyone. -Four cells in box for every combination type line/width. -Only with black lines. Even in 400% scale most of them do not appear as I think would expected, not better exporting to pdf. Win7x64 LibreOffice Version 3.6.2.1 (Build ID: ba822cc) Win7x64 LibreOffice Version 3.7.0.0.alpha0+ (Build ID: f49db87) Not well but looks better in LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.4.1
I compared my test results from "test results" 2012-02-22 09:17 UTC, Rainer Bielefeld with results using "LibreOffice 3.6.3.2” German UI/ German Locale [Build-ID: 58f22d5] on German WIN7 Home Premium (64bit): Looks more or less perfect. So I close this one WFM @all: If you still see problems looking related to the original report please submit a new bug with reference the the sample documents here and a clear description due to <http://wiki.documentfoundation.org/BugReport>: Not: Some lines do not print But: Border between B3 and C3 ...
I tested in Lo 3.6.3.2. While it's better than in 3.5.x, it's far from perfect. Lines are not even.
*** Bug 55077 has been marked as a duplicate of this bug. ***
With Version 4.1.0.0.alpha0+ (Build ID: 80cbc04c2cbe25ebdfe2f22bb2e5ba62728e963) on Bodhi Linux the borders look perfect. I downloaded Some lines do not print.ods and printed to pdf, comparing the documents all lines look good. I am closing this as WORKSFORME. @Timur - if this is still a problem please attach a new pdf that shows us what you currently see with latest stable release. Also, if you feel inclined to reopen this bug please remove 3.5 MAB as 3.5 is at EOL and therefore will not be looked at further. We are currently in the process of closing 3.5 MAB meta tracker.
Created attachment 74758 [details] Bad print 4.0.0
Created attachment 74759 [details] Bad print 4.0.1 nightly
Created attachment 74760 [details] Bad print 4.1.0 nightly
Still doesn't print some borders, tested with 4.0.0, 4.0.1 nightly and 4.1.0 nightly on Windows 7 x64. Also print preview is even more broken than the actual print, it's totally unusable, it doesn't show even half of the borders that should be there with the test document. OT: Why does "add attachment" default to text/plain instead of autodetect? That's annoying as hell.
Still massive problems [Reproducible] with server installation of "Version 4.1.0.0.alpha0+ (Build ID: 576da8db5577f84d9c7e0e40ef3e166a7938c98) TinderBox: Win-x86@6, Branch:master, Pull Time: 2013-02-11_23:54:45" ENGLISH UI / German Locale on German WIN7 Home Premium (64bit) with own separate User Profile. But this bug can not be fixed, may we need separate bugs for each separate problem. We have to many relations here (XLS?) In so far I agree with Joel's Idea to close this one, we are in a dead end here. Sample "LibreOffice_Test-Sample_Menu-Format-Cell-Borders_V01_LiboV3621_en-us" seems to be a really good test case, so I think we should use it to submit new bugs citing the attachment here in the way I demonstrate with "Bug 60803 - PRINTING: some 0,05pt borders shown in pale grey instead of solid black" @Joel: Borders look perfect for me is a very rare statement for such a complex thing :-/ We have various sample documents, I wonder what one you used for your tests? @khagaroth@gmail.com Please do not spam this bug with more or less identical pdf's without explication how you created them and what exactly the problem is. Please also keep in mind <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>!
Can someone confirm "Bug 60805 - VIEWING: Particular border style and width invisible for zoom 100%"?
We are working on getting it to auto detect - thanks for the update
Changing MAB to 3.6 because 3.5 bug tracker is being closed (due to EOL)
Hm, I see serious problems in a FREEOdf print, and I also see serious problems in a Laser Printer (Samsung CLX-3185FN) print (both WIN 4.1.0.0+), but the results are not similar at all. I will attach a scan, but the quality is not sufficient. Any Idea how we can get a common way to compare the rswults for further tests?
Created attachment 74811 [details] Test-Sample_Menu-Format-Cell-Borders_V01_LiboV3621.ods opened and printed in LO365 and LOdev401 Please look at some screenshots of Test-Sample_Menu-Format-Cell-Borders_V01_LiboV3621.ods file taken at different zoom percentages with LO365 and LOdev401 on Win7 and attached in ZIP file. LO365 shows all borders, although unevenly. LOdev401 shows all borders on 100% and 200% zoom, while it doesn't show some, different borders on zooms 110%, 140%, 160%. Same ODS exported and printed on virtual PDF printers behave differently (in the same PDF viewer).
moving this from mab3.6 to mab4.0 since 3.6.x is EOL.
Restricted my LibreOffice hacking area
Fix fro Bug 73487 should help address this. Anyway, the border lines have been overhauled in 4.2.1.
And please don't reopen this bug anymore. File a new one for any border line issues.
and only of course if you can verify issues on 4.2.1 or later - do not file new bugs that you see on 4.1 unless you can confirm they are on 4.2 as Kohei has just said major work was done in 4.2. Thanks!