Bug 136957 - FILEOPEN PPTX: dotted line partially disappears in presentation mode (only)
Summary: FILEOPEN PPTX: dotted line partially disappears in presentation mode (only)
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All All
: medium normal
Assignee: Gülşah Köse
URL:
Whiteboard: target:7.2.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Slide-Show
  Show dependency treegraph
 
Reported: 2020-09-22 16:16 UTC by Gerald Pfeifer
Modified: 2021-01-22 12:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample PPTX document, all four slides are affected (665.24 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2020-09-22 16:16 UTC, Gerald Pfeifer
Details
Visual comparison presentation mode vs edit mode (both LibreOffice) (49.10 KB, image/png)
2020-09-22 16:18 UTC, Gerald Pfeifer
Details
slide with all OOXML preset dash pattern, width 1pt (11.10 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2020-12-02 18:04 UTC, Regina Henschel
Details
Screenshot of slide 3 of the initial sample document - edit view vs presentation view (120.74 KB, image/png)
2020-12-04 13:56 UTC, Gerald Pfeifer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2020-09-22 16:16:00 UTC
Created attachment 165780 [details]
Sample PPTX document, all four slides are affected

This likely is somewhat related to bug#134053 ("FILEOPEN PPTX: dotted line shows as solid"); at least it's the same template.

I noticed that the attached four slides look perfectly fine in edit mode,
alas when presented parts of the dotted lines simply disappear.


Regina, you kindly fixed bug#134053 and I figured you might be interested.
Comment 1 Gerald Pfeifer 2020-09-22 16:18:58 UTC
Created attachment 165781 [details]
Visual comparison presentation mode vs edit mode (both LibreOffice)

Version: 7.0.1.2
Build ID: 00(Build:2)
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.1.0.0.alpha0+
Build ID: 40f42f317757ef02d0a4d1cfd1c4f5bd8583e8e0
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-09-20_14:51:16
Calc: threaded
Comment 2 Telesto 2020-09-22 21:35:03 UTC
Repro
Version: 7.1.0.0.alpha0+ (x64)
Build ID: abcc4eb907661e07ad850ccce7eb06f129da4286
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 3 Telesto 2020-09-22 21:35:50 UTC
Still fine with
Version: 6.0.6.0.0+
Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 4 Regina Henschel 2020-09-23 12:32:26 UTC
(In reply to Gerald Pfeifer from comment #0)
> Regina, you kindly fixed bug#134053 and I figured you might be interested.

It is a rendering problem. That is outside my field of experience.

If you set the line width to 1mm, the dots are rendered nicely. If I save the file to odp and look into the file text, I see the correct definition too.

It seems, the rendering engine of the slideshow has problems to draw rounded caps, if the line width is smaller than some threshold.

(In reply to Telesto from comment #3)
> Still fine with
> Version: 6.0.6.0.0+

Older versions of LibreOffice imported (erroneously) a round dot of PowerPoint as square, so as if "Flat" cap was specified in PowerPoint. You can still use this as workaround and set the cap of such thin lines to "Flat" in PowerPoint. Then you will get little squares as in older versions.
Comment 5 raal 2020-09-23 13:34:28 UTC
bisected

cf50cc10587c1696bc79d51d6fc90a8c8b547293 is the first bad commit
commit cf50cc10587c1696bc79d51d6fc90a8c8b547293
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Mon Jun 22 03:42:24 2020 -0700

    source sha:3f3b50015e4fd9efc3459612a70409fca49cf390

https://gerrit.libreoffice.org/c/core/+/96769
Adding cc to: Regina Henschel
Comment 6 Gerald Pfeifer 2020-10-24 15:04:40 UTC
Norbert, if I understand correctly this regression was bisected to a
commit of yours.

Would you mind having a look, please?  (And sorry if I got confused.)
Comment 7 Aron Budea 2020-10-24 16:42:55 UTC
Actually, it's been bibisected to Regina's commit, the commit that goes under Norbert's name is the one in the bibisect repository, and is not relevant. The relevant commit hash is always what follows "source sha:", which points to a commit in the LibreOffice repository.

Raal gave the gerrit link in addition, which is another way to point to the change. The commit itself is the following:
https://git.libreoffice.org/core/+/3f3b50015e4fd9efc3459612a70409fca49cf390%5E%21
or
https://cgit.freedesktop.org/libreoffice/core/commit/?id=3f3b50015e4fd9efc3459612a70409fca49cf390
author		Regina Henschel <rb.henschel@t-online.de>	2020-06-20 15:08:12 +0200
committer	Regina Henschel <rb.henschel@t-online.de>	2020-06-22 10:43:08 +0200

tdf#134053 tweak dash and space length for ooxml
Comment 8 Gerald Pfeifer 2020-10-29 23:28:58 UTC
(In reply to Aron Budea from comment #7)
> Actually, it's been bibisected to Regina's commit, the commit that goes
> under Norbert's name is the one in the bibisect repository, and is not
> relevant. The relevant commit hash is always what follows "source sha:",
> which points to a commit in the LibreOffice repository.

Ah, thank you for the background, Aron.

Thanks also for your color, Regina. I'll see how we can address this one.
Comment 9 Commit Notification 2020-12-02 13:07:54 UTC
Gülşah Köse committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5d80f679e1891f98ef964efa1166c90d001c5806

tdf#136957 Use bigger dots for better handling in presentation mode.

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Regina Henschel 2020-12-02 18:04:38 UTC
Created attachment 167771 [details]
slide with all OOXML preset dash pattern, width 1pt

Please check the dash-dot patterns. From your code I guess, that the dots are still missing in those pattern. (Need to wait for the daily build to test it myself.)
Comment 11 Regina Henschel 2020-12-03 08:34:00 UTC
Tested now, the dots in mixed patterns are indeed still missing in slideshow.

You need to know that "dots" and "dashes" in code does not mean literally "dot" or "dash". But "dots" means "first" in a mixed pattern and "dashes" means "second". BTW, mixed pattern in OOXML always start with a (literal) "dash".

So please change 99 to 96 for "dashes" too.
Comment 12 Gerald Pfeifer 2020-12-04 13:51:06 UTC Comment hidden (obsolete)
Comment 13 Gerald Pfeifer 2020-12-04 13:54:56 UTC
(In reply to Commit Notification from comment #9)
> https://git.libreoffice.org/core/commit/
> 5d80f679e1891f98ef964efa1166c90d001c5806
 :
> Affected users are encouraged to test the fix and report feedback.

This commit indeed addresses dots disappearing from the four slides in
my sample PPTX document.

Unfortunately slide 3 in particular looks really different now between
edit mode and presentation mode: The dotted line (top half) looks lighter
than the full line (bottom half) in edit mode. After this patch this is
reversed - at least to my eyes.

The commit message says

  "3 pt bigger dots are used. Human eye can't catch this
  change so we will see same dots in edit mode and presentation mode."

but I promise I am human. ;-)
Comment 14 Gerald Pfeifer 2020-12-04 13:56:18 UTC
Created attachment 167831 [details]
Screenshot of slide 3 of the initial sample document - edit view vs presentation view
Comment 15 Regina Henschel 2020-12-07 19:28:38 UTC
I guess, that there is a problem with conversion to integer:
(old) 1% of 1pt = 0.3527777 1/100mm, round down to zero, not visible
(new) 4% of 1pt = 1.4111111 1/100mm, round down to 1, visible
(new) 4% of 0.25pt =0.3527777 1/100mm, round down to zero, not visible
It seems that somewhere drawing is skipped, if the dash length is zero, without considering, that dash caps have to be drawn.


BTW, I miss points in the vertical part of the dotted line in slide 4 in slideshow mode.


The problem with the dotted lines in edit mode might be a problem with the used renderer. I recently (bug 134128) fixed a problem with GDI+ on Windows. But I have no Linux environment.
@Gerald: Is it possible to choose a different renderer on Linux. Here on Windows I can use GDI+ (=default) or Skia. Setting is in Tools > Options > Libreoffice > View. If yes, please test it.