Bug 139264 - The dash count of footnote separator lines change depending on zoom level
Summary: The dash count of footnote separator lines change depending on zoom level
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Footnote-Endnote Zoom
  Show dependency treegraph
 
Reported: 2020-12-27 17:19 UTC by Telesto
Modified: 2024-08-07 19:19 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (9.50 KB, application/vnd.oasis.opendocument.text)
2020-12-27 17:19 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-12-27 17:19:18 UTC
Description:
Footnote Separator line dashes fuzz and unfuzz depending on zoomlevel 

Steps to Reproduce:
1. Open the attached file
2. Zoom in
3. Zoom out

Actual Results:
Number of dashes depends on zoom level.. sometimes it will be a straight line (25 zoomlevel0

Expected Results:
Dashes should be visible


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.0.0.alpha0+ (x64)
Build ID: 315c7570c4a72f4c834086082825533b1e50d1bf
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-12-27 17:19:36 UTC
Created attachment 168522 [details]
Example file
Comment 2 Telesto 2020-12-27 17:22:33 UTC
Also in
4.4.7.2

still OK (or at least that's my impression) in
Versie: 4.2.0.4 
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Comment 3 Telesto 2020-12-27 17:24:28 UTC
@Regina
As I think you might be interested in this type of thing (in the sense of in the loop)..
Comment 4 Telesto 2020-12-27 17:24:43 UTC
Also in
Version: 4.3.7.2
Build ID: 8a35821d8636a03b8bf4e15b48f59794652c68ba
Comment 5 Dieter 2021-05-23 10:21:34 UTC
I confirm it with

Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 4a9eef7849a75ba91806886ea9c96d114c8d56f9
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 6 Sophie Sipasseuth 2023-05-23 08:33:15 UTC
No repro

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: f4c24da1e7f11664e0d2f688d2531f068e4a3bc0
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL threaded
Comment 7 Buovjaga 2024-08-07 19:19:04 UTC
Bibisecting with Linux 43max, there was also an intermediate state where the line was dashed differently than originally, but did not change when zooming. When marking it as bad, there were a lot of bad commits to skip. The range was

https://git.libreoffice.org/core/+log/9e18f7e3cfec960b788eb5df3b53daf9efd092ab..f2ff3b10547a7a3f31a8dd885a004e5f4bec1377
where I assume the change is f2ff3b10547a7a3f31a8dd885a004e5f4bec1377
Pass scaling to borderline primitive objects.

...which is runnable in the repo.

Then, bibisecting with that one as good and latest as bad, I got an exact commit explaining our current state: 0a8ddb61b1178a7ab48de7aa3383cea4c4c1774c
Apply dashing without consulting current map unit.

Using scaling is sufficient.