Bug 136957 - FILEOPEN PPTX: dotted line partially disappears in presentation mode (only)
Summary: FILEOPEN PPTX: dotted line partially disappears in presentation mode (only)
Status: VERIFIED FIXED
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: Not Assigned
URL:
Whiteboard: target:7.2.0 target:7.1.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Slide-Show
  Show dependency treegraph
 
Reported: 2020-09-22 16:16 UTC by Gerald Pfeifer
Modified: 2021-06-10 11:58 UTC (History)
7 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
attachment #167771 in todays build, slideshow mode (59.92 KB, image/jpeg)
2021-04-30 13:31 UTC, Gabor Kelemen (allotropia)
Details
Test result (16.57 KB, image/png)
2021-04-30 13:31 UTC, László Németh
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.
Comment 16 Commit Notification 2021-04-29 14:06:47 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

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

Revert "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 17 Commit Notification 2021-04-29 14:06:58 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b71d9a6d15cfb8a50afdea5ac064f40d84c561f8

do not apply line dashing in drawinglayer (tdf#136957)

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 18 Luboš Luňák 2021-04-29 14:08:33 UTC
Can you please try with a tomorrow's build from https://dev-builds.libreoffice.org/daily/master/ whether this is ok now?
Comment 19 Gabor Kelemen (allotropia) 2021-04-30 13:31:17 UTC
Created attachment 171532 [details]
attachment #167771 [details] in todays build, slideshow mode

In todays build the attachment 167771 [details] loses the dots in dot-line and dot-dot-line type lines in presentation mode (but the document still looks good in the editor):

Version: 7.2.0.0.alpha0+
Build ID: 6b7c2fa65eb68be520ed4135cc245e33fa22e8bf
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: hu-HU (hu_HU.UTF-8); UI: en-US
Calc: threaded
Comment 20 László Németh 2021-04-30 13:31:50 UTC
Created attachment 171533 [details]
Test result
Comment 21 Gerald Pfeifer 2021-04-30 16:47:35 UTC
(In reply to Luboš Luňák from comment #18)
> Can you please try with a tomorrow's build from
> https://dev-builds.libreoffice.org/daily/master/ whether this is ok now?

The originally reported issue appears nicely addressed now, thank you!

Alas, indeed it seems there is a regression as Gabor describes in 
comment #19?

(In the end I believe the patch improves the situation more than it
regresses, so would not recommend to revert.)
Comment 22 Gerald Pfeifer 2021-04-30 17:55:04 UTC
(In reply to Regina Henschel from comment #15)
> @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.

Apologies, Regina, I failed to follow up on this originally. I do not see
the option to choose a different rednerer on Linux.

HOWEVER, you hit gold!  

There is an option "Use hardware acceleration". If I _disable_ that, the 
dash-dot-dot patterns, lines #6 and #9 show the dots in presentation mode.

If I keep it enabled, no dots in lines #6 and #9 in presentation mode.


@Gabor, @László, can you reproduce this?

@Lubos, does that help?

(My graphics system is a plain Intel i915, X.org, all open source, latest
version of openSUSE Tumbleweed.)
Comment 23 Commit Notification 2021-04-30 22:18:37 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/565824df07913f47851804daed9efa28a4a95e9d

fix dashed line info conversion for metafile (tdf#136957)

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 24 Buovjaga 2021-05-02 14:51:20 UTC
Needinfo is dangerous (auto-closing), so mainly use it for unconfirmed reports lacking info
Comment 25 Gerald Pfeifer 2021-05-02 18:56:18 UTC
From what I can tell, testing 

Version: 7.2.0.0.alpha0+
Build ID: fe2f5f99636d938d57c1880c37d54c1b796f06f1
CPU threads: 8; OS: Linux 5.11; 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: 2021-05-01_07:51:19

this appears to address the original report while avoiding regressions,
regardless of whether I have activated hardware acceleration or not.
Thank you!

@Gabor, @László, can you confirm the same?

@Lubos, is there any chance for a regression test?
Comment 26 László Németh 2021-05-05 07:30:01 UTC
@Luboš: the dots of the thin lines are visible now, thanks. Unfortunately, the lengths are still bad, e.g. the dashed line of the unit test document sd/qa/unit/data/pptx/tdf134053_dashdot.pptx has been shown as a solid line during presentation.
Comment 27 Luboš Luňák 2021-05-05 18:00:03 UTC
(In reply to Gerald Pfeifer from comment #25)
> @Lubos, is there any chance for a regression test?

I've written one. It's currently pending on another refactor change, but I'll push the test once this is sorted out.

Does this mean the bugreport can be closed?

(In reply to László Németh from comment #26)
> @Luboš: the dots of the thin lines are visible now, thanks. Unfortunately,
> the lengths are still bad, e.g. the dashed line of the unit test document
> sd/qa/unit/data/pptx/tdf134053_dashdot.pptx has been shown as a solid line
> during presentation.

https://gerrit.libreoffice.org/c/core/+/115147
Comment 28 Gerald Pfeifer 2021-05-05 20:47:01 UTC
(In reply to Luboš Luňák from comment #27)
>> @Lubos, is there any chance for a regression test?
> I've written one. It's currently pending on another refactor change, but
> I'll push the test once this is sorted out.

Cool, thank you!

> Does this mean the bugreport can be closed?

I can't speak for László and Gabor, but from what I can see it looks
good. :-) 

László, Gabor?
Comment 29 Commit Notification 2021-05-06 02:07:19 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/57595773df9f89245457443a3def786fa0e70a69

do not apply line dashing in drawinglayer (tdf#136957)

It will be available in 7.1.4.

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 30 Commit Notification 2021-05-06 02:07:30 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/f34ab6e4a85ce5cc9eb33319601840afac90237b

fix dashed line info conversion for metafile (tdf#136957)

It will be available in 7.1.4.

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 31 Commit Notification 2021-05-06 09:24:19 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7603d51e7747a0ea2e628bd467af7d17597a9b10

add a unittest for impress drawing a dotted line in tdf#136957

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 32 NISZ LibreOffice Team 2021-05-07 07:08:43 UTC
I see the attachment 167771 [details] looks good now in Skia mode on Windows, as well as the attachment 171440 [details] from bug 141296.

They look somewhat bad in GDI-mode though: the 1pt line styles example has no dots in GDI slideshow view.
The 2 pt dash-dot line from attachment 171440 [details] appears without dots and with a lot of space between the dashes.
Comment 33 Commit Notification 2021-05-07 12:31:04 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ec73a21bccf4a055ae9dc575dbad3d67c91f481e

set also dashing cap style for directx canvas (tdf#136957)

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 34 Commit Notification 2021-05-08 15:13:36 UTC
Luboš Luňák committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/c4813202f7eddc78c5c8d49a46f5434bc23547b1

set also dashing cap style for directx canvas (tdf#136957)

It will be available in 7.1.4.

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 35 NISZ LibreOffice Team 2021-05-10 10:02:43 UTC
I just checked how it looks after the latest patches.

Now dashes and dots both appear in Skia and GDI mode too.

I think this bug can be closed.

Remaining issue is documented in bug 141926

with a newer example file and screenshots: in GDI slideshow mode the dashes and the space between them is much longer than in the editor view and this gets kinda ugly with larger line widths such as 5-10 pt.
Comment 36 Gerald Pfeifer 2021-05-10 10:19:28 UTC
(In reply to NISZ LibreOffice Team from comment #35)
> I just checked how it looks after the latest patches.
> 
> Now dashes and dots both appear in Skia and GDI mode too.
> 
> 
> Remaining issue is documented in bug 141926
> 
> with a newer example file and screenshots: in GDI slideshow mode the dashes
> and the space between them is much longer than in the editor view and this
> gets kinda ugly with larger line widths such as 5-10 pt.


> I think this bug can be closed.

Excellent, thank you. With that and my comment #28 indeed this appears
nicely resolved. :-)

And thank you, Luboš. As committer, do you want to mark this as RESOLVED,
or should one of us do it?
Comment 37 Luboš Luňák 2021-05-11 11:27:12 UTC
I don't particularly care, as long as it's fixed :). Closing.
Comment 38 NISZ LibreOffice Team 2021-06-10 11:58:17 UTC
Verified in:
Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: aa9cb8e14749e7fb7a83b55a2bb095501f731a18
CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: hu-HU
Calc: threaded