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.
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
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
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
(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.
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 3f3b50015e4fd9efc3459612a70409fca49cf390 https://gerrit.libreoffice.org/c/core/+/96769 Adding cc to: Regina Henschel
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.)
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
(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.
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.
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.)
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.
(In reply to Commit Notification from comment #9) > https://git.libreoffice.org/core/commit/ > 5d80f679e1891f98ef964efa1166c90d001c5806 > > tdf#136957 Use bigger dots for better handling in presentation mode. 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 The commit message of that 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."
(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. ;-)
Created attachment 167831 [details] Screenshot of slide 3 of the initial sample document - edit view vs presentation view
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.
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.
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.
Can you please try with a tomorrow's build from https://dev-builds.libreoffice.org/daily/master/ whether this is ok now?
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
Created attachment 171533 [details] Test result
(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.)
(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.)
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.
Needinfo is dangerous (auto-closing), so mainly use it for unconfirmed reports lacking info
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?
@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.
(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
(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?
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.
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.
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.
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.
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.
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.
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.
(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?
I don't particularly care, as long as it's fixed :). Closing.
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