Bug 67923 - FORMATTING: when page scaling factor is >100%, thin border lines (0.05pt) are exported to PDF with different line widths, some are practically invisible
Summary: FORMATTING: when page scaling factor is >100%, thin border lines (0.05pt) are...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.5.3 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:pdf, regression
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2013-08-08 22:56 UTC by Mike Kaganski
Modified: 2019-12-03 14:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
ODS and PDF from LO v3572, v4162, v4252, and v4303. (73.24 KB, application/zip)
2014-07-28 13:37 UTC, Owen Genat (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2013-08-08 22:56:51 UTC
When page scaling factor is >100%, thin border lines (0.05pt) are exported to PDF with different line widths, some are practically invisible.

Steps to reproduce:

1. Create a new spreadsheet.
2. Apply black thin borders (0.05pt).
3. Menu Format->Page...->Sheet->Scaling mode: Reduce/enlarge printout; Scaling factor: 130%
4. Export to PDF with default settings.

Expected result: the borders are visible and consistent in resulting PDF.

Actual result: the borders have different widths: some look normal, some have zero width (almost invisible at any zoom, up to 6400%).

This problem happens at any scaling factor >100%. Scaling factors <=100% are OK.

Please note that this is not a reader-dependent problem: if you import the PDF to draw, you may see that these hairlines are thinner there, too. Setting line widths in imported drawing makes this clear.

The test kit is attachment 83868 [details] from bug 67898.

Affected: all versions starting from 3.5.5.3 up to 4.1.0.4.
Not affected: 3.5.4.2 -> regression.

Tested under Win7x64.
Comment 1 Mike Kaganski 2013-08-08 22:58:21 UTC
This bug and bug 67898 appeared simultaneously; they must be caused by one or related commits.
Comment 2 ign_christian 2014-07-02 15:15:41 UTC
Similar result as my test in Bug 67898, "Export as PDF" produces unexpected result. Not different width, but it's too thin.
Using PDF printer looks good (I only test in CUPS PDF). 

LO 4.2.5.2 and 4.3.0.1 - Ubuntu 12.04 x86
Comment 3 Owen Genat (retired) 2014-07-28 13:37:25 UTC
Created attachment 103591 [details]
ODS and PDF from LO v3572, v4162, v4252, and v4303.

(In reply to comment #0)
> 1. Create a new spreadsheet.
> 2. Apply black thin borders (0.05pt).
> 3. Menu Format->Page...->Sheet->Scaling mode: Reduce/enlarge printout;
> Scaling factor: 130%
> 4. Export to PDF with default settings.

I found it easier to first format the page and then apply borders to an area of cells that would fit on a single page at the indicated zoom level, but otherwise confirmed. Tested under GNU/Linux using:

- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
- v4.2.5.2 Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5
- v4.3.0.3 Build ID: 08ebe52789a201dd7d38ef653ef7a48925e7f9f7

Examples from these versions attached. Output varies across versions.
Comment 4 Owen Genat (retired) 2014-07-28 13:41:03 UTC
As per comment 3 status set to NEW. I guess this report may be closed as a duplicate of bug 67898, but for now I have confirmed this one.
Comment 5 ign_christian 2014-07-29 05:46:36 UTC
I think this bug reported against "Export as PDF", real printing should be different problem.

Set Platform All per comment 2
Comment 6 Matthew Francis 2014-12-06 06:17:29 UTC
Results from bibisect-43all:

f3986117cf91f1976749922e435915354389c4f1 is the first bad commit
commit f3986117cf91f1976749922e435915354389c4f1
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed May 2 19:12:54 2012 +0200

    source-hash-eab7e131ecebe4cdefcdcb1ad176bbdce83cb467
    
    commit eab7e131ecebe4cdefcdcb1ad176bbdce83cb467
    Author:     Ivan Timofeev <timofeev.i.s@gmail.com>
    AuthorDate: Sat Apr 7 21:20:48 2012 +0400
    Commit:     Ivan Timofeev <timofeev.i.s@gmail.com>
    CommitDate: Sun Apr 8 14:25:44 2012 +0400
    
        starmath: fix DEBUG_ENABLE_DUMPASDOT build

# bad: [2e0fa432485d1db6abd355dad8ccb06f0b97e4fb] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'last40onmaster' 'oldest'
# bad: [aed6d9e275e4560aa251d23dd7ba6a0a725afab7] source-hash-c77918bb03974ff9be90c889f77e62ea0755052f
git bisect bad aed6d9e275e4560aa251d23dd7ba6a0a725afab7
# good: [5313c0086bde1a424c33b54120f14c4c79989cf7] source-hash-243fbda523cb71d0919539081d286eec4717ce15
git bisect good 5313c0086bde1a424c33b54120f14c4c79989cf7
# good: [f23b0ac1f569b0e043ebc0d0fe08ec76ea23d656] source-hash-552ba413bc95b1a14638558d9436141825100c52
git bisect good f23b0ac1f569b0e043ebc0d0fe08ec76ea23d656
# bad: [13312242b4c33dfbbf82238d6e47bbefdaf22f32] source-hash-33f5acad371bcf838011b3629450e6dcd405a4e9
git bisect bad 13312242b4c33dfbbf82238d6e47bbefdaf22f32
# bad: [9e82321771f66f258d72d9027cbb30598827becf] source-hash-d31997559adac6f03d932cb6c5819149c38c1398
git bisect bad 9e82321771f66f258d72d9027cbb30598827becf
# bad: [001b8be798d9875b6f699c573f4147d04caece67] source-hash-ee7084c4f720c932df67c8ff033dab4d8d556179
git bisect bad 001b8be798d9875b6f699c573f4147d04caece67
# bad: [f3986117cf91f1976749922e435915354389c4f1] source-hash-eab7e131ecebe4cdefcdcb1ad176bbdce83cb467
git bisect bad f3986117cf91f1976749922e435915354389c4f1
# good: [cef0750df9186e2523a1a2d1ddb4c1ddbb85c19d] source-hash-18c661f715a0b6850d30b374e5556dc14a377d2b
git bisect good cef0750df9186e2523a1a2d1ddb4c1ddbb85c19d
# first bad commit: [f3986117cf91f1976749922e435915354389c4f1] source-hash-eab7e131ecebe4cdefcdcb1ad176bbdce83cb467
Comment 7 Matthew Francis 2015-01-16 00:49:23 UTC
The last time all the borders were shown correctly in the PDF appears to have been before the below commit

Adding Cc: to markus.mohrhard@googlemail.com; Could you possibly take a look at this? Thanks


commit 2c91cb08d65cd35fa8ef6eaca3677aa82fb58cbe
Author: Markus Mohrhard <markus.mohrhard@googlemail.com>
Date:   Wed Apr 4 01:58:07 2012 +0200

    better drawing support for borders of different width, fdo#33634
Comment 8 Robinson Tryon (qubit) 2015-12-13 11:09:40 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2016-09-26 17:07:21 UTC
Adding Cc: to Markus Mohrhard
Comment 10 QA Administrators 2017-10-30 08:32:55 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2019-12-03 14:11:21 UTC
Dear Mike Kaganski,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug