Bug 46393 - [Task] PRINTING result for cell borders of particular documents unsatisfying
Summary: [Task] PRINTING result for cell borders of particular documents unsatisfying
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: All All
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard: target:4.2.1
Keywords: regression
: 55077 (view as bug list)
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-02-21 05:20 UTC by Timur
Modified: 2014-02-07 06:28 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
LO bug 46393 - Some lines do not print (34.11 KB, application/pdf)
2012-02-21 05:22 UTC, Timur
Details
LO bug 46393 - Reapplied border lines do print (32.92 KB, application/pdf)
2012-02-21 05:23 UTC, Timur
Details
LO bug 46393 - Some lines do not print.ods (18.61 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-02-21 05:23 UTC, Timur
Details
LO bug 46393 - Same lines do print in OO (PDF) (33.19 KB, application/octetstream)
2012-02-22 04:21 UTC, Timur
Details
test results (266.28 KB, application/zip)
2012-02-22 09:17 UTC, Rainer Bielefeld Retired
Details
LibreOffice_Test-Sample_Menu-Format-Cell-Borders_V01_LiboV3621_en-us (14.72 KB, application/x-vnd.oasis.opendocument.spreadsheet)
2012-09-16 23:25 UTC, m.a.riosv
Details
Bad print 4.0.0 (80.74 KB, application/pdf)
2013-02-13 15:31 UTC, khagaroth
Details
Bad print 4.0.1 nightly (80.80 KB, application/pdf)
2013-02-13 15:32 UTC, khagaroth
Details
Bad print 4.1.0 nightly (80.80 KB, application/pdf)
2013-02-13 15:33 UTC, khagaroth
Details
Test-Sample_Menu-Format-Cell-Borders_V01_LiboV3621.ods opened and printed in LO365 and LOdev401 (608.64 KB, application/zip)
2013-02-14 12:43 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2012-02-21 05:20:49 UTC
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.
Comment 1 Timur 2012-02-21 05:22:26 UTC
Created attachment 57390 [details]
LO bug 46393 - Some lines do not print
Comment 2 Timur 2012-02-21 05:23:06 UTC
Created attachment 57391 [details]
LO bug 46393 - Reapplied border lines do print
Comment 3 Timur 2012-02-21 05:23:45 UTC
Created attachment 57392 [details]
LO bug 46393 - Some lines do not print.ods
Comment 4 Timur 2012-02-22 04:21:00 UTC
The same "Some lines do not print" tab from "Some lines do not print.ods" prints correctly with OO 3.3.0.
Comment 5 Timur 2012-02-22 04:21:47 UTC
Created attachment 57449 [details]
LO bug 46393 - Same lines do print in OO (PDF)
Comment 6 sasha.libreoffice 2012-02-22 07:02:26 UTC
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
Comment 7 sasha.libreoffice 2012-02-22 07:07:17 UTC
reproduced in 3.4.2, but not reproduced in 3.3.4, therefore regression since 3.3.4
Comment 8 sasha.libreoffice 2012-02-22 07:10:12 UTC
@ Kohei
Please, take look at this when will have time. Regression since 3.3.4 in exporting to pdf.
Comment 9 Rainer Bielefeld Retired 2012-02-22 09:16:30 UTC
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
Comment 10 Rainer Bielefeld Retired 2012-02-22 09:17:47 UTC
Created attachment 57470 [details]
test results

Borders in exports from versions later than 3.3 look horrible in AR-X
Comment 11 Markus Mohrhard 2012-04-02 18:37:36 UTC
Suspected duplicate of Bug 33634
Comment 12 Timur 2012-04-04 01:47:16 UTC
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.
Comment 13 Rainer Bielefeld Retired 2012-04-04 02:14:32 UTC
@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.
Comment 14 Markus Mohrhard 2012-04-04 21:59:14 UTC
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.
Comment 15 Timur 2012-04-05 06:46:38 UTC
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.
Comment 16 Michael Stahl (CIB) 2012-05-24 03:24:57 UTC
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...
Comment 17 m.a.riosv 2012-09-16 23:25:29 UTC
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
Comment 18 Rainer Bielefeld Retired 2012-10-26 05:04:53 UTC
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 ...
Comment 19 Timur 2012-10-30 13:59:32 UTC
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.
Comment 20 Michael Stahl (CIB) 2012-10-31 19:23:00 UTC
*** Bug 55077 has been marked as a duplicate of this bug. ***
Comment 21 Joel Madero 2013-02-12 18:06:25 UTC
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.
Comment 22 khagaroth 2013-02-13 15:31:47 UTC
Created attachment 74758 [details]
Bad print 4.0.0
Comment 23 khagaroth 2013-02-13 15:32:39 UTC
Created attachment 74759 [details]
Bad print 4.0.1 nightly
Comment 24 khagaroth 2013-02-13 15:33:13 UTC
Created attachment 74760 [details]
Bad print 4.1.0 nightly
Comment 25 khagaroth 2013-02-13 15:38:25 UTC
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.
Comment 26 Rainer Bielefeld Retired 2013-02-13 16:49:43 UTC
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>!
Comment 27 Rainer Bielefeld Retired 2013-02-13 17:00:02 UTC
Can someone confirm "Bug 60805 - VIEWING: Particular border style and width invisible for zoom 100%"?
Comment 28 Joel Madero 2013-02-13 17:34:16 UTC
We are working on getting it to auto detect - thanks for the update
Comment 29 Joel Madero 2013-02-13 17:39:49 UTC
Changing MAB to 3.6 because 3.5 bug tracker is being closed (due to EOL)
Comment 30 Rainer Bielefeld Retired 2013-02-13 20:27:25 UTC
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?
Comment 31 Timur 2013-02-14 12:43:07 UTC
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).
Comment 32 tommy27 2013-08-18 15:19:16 UTC
moving this from mab3.6 to mab4.0 since 3.6.x is EOL.
Comment 33 Cédric Bosdonnat 2014-01-20 09:00:37 UTC
Restricted my LibreOffice hacking area
Comment 34 Kohei Yoshida 2014-02-07 06:06:43 UTC
Fix fro Bug 73487 should help address this.  Anyway, the border lines have been overhauled in 4.2.1.
Comment 35 Kohei Yoshida 2014-02-07 06:14:54 UTC
And please don't reopen this bug anymore.  File a new one for any border line issues.
Comment 36 Joel Madero 2014-02-07 06:28:41 UTC
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!