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: RESOLVED WORKSFORME
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 tree / graph
 
Reported: 2013-08-08 22:56 UTC by Mike Kaganski
Modified: 2021-12-03 11:26 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
View All Add an attachment (proposed patch, testcase, etc.)

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 Comment hidden (obsolete)
Comment 12 QA Administrators 2021-12-03 04:29:15 UTC Comment hidden (obsolete)
Comment 13 Mike Kaganski 2021-12-03 11:26:59 UTC 
Seems to be working fine with Version: 7.2.3.2 (x64) / LibreOffice Community
Build ID: d166454616c1632304285822f9c83ce2e660fd92
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: default; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded